Desacelerações do proxy ao longo do tempo: verifique conntrack e limites de recursos
Investigue a pressão do rastreamento de conexões junto com os limites de recursos do proxy e do host quando as falhas se acumulam ao longo do tempo.
O proxy responde após uma reinicialização. Algumas horas depois, as novas conexões travam. Reiniciá-lo compra outro intervalo tranquilo. Esse padrão sugere um estado que se acumula, mas não identifica qual estado é o responsável.
Num caminho Linux que usa rastreamento de conexões, um candidato é a tabela conntrack. Verifique estes valores existentes na máquina e no namespace de rede que trata do tráfego:
/proc/sys/net/netfilter/nf_conntrack_count
/proc/sys/net/netfilter/nf_conntrack_maxO primeiro relata entradas de fluxo alocadas; o segundo as limita. Não são contagens de utilizadores do Squid nem de pedidos HTTP. O estado de fluxo do núcleo pode sobreviver ao trabalho ativo da aplicação.
Procure uma relação, não apenas um número grande
Compare a ocupação ao longo do tempo com o início das falhas nas novas conexões e com mensagens relevantes do núcleo. Uma contagem alta sem provas de falha correspondentes é diferente de uma tabela que atinge repetidamente o limite exatamente quando os pedidos começam a expirar.
A tabela pode servir mais do que o proxy. Outros serviços locais, tráfego encaminhado ou outro caminho de rede ocupado podem contribuir. O facto de reiniciar o proxy alterar o sintoma não prova que a cache de objetos do Squid tenha sido a causa.
Mantenha as explicações concorrentes à vista: descritores de ficheiro, filas dos auxiliares de autenticação, atrasos de DNS, pressão de memória e um sistema de ficheiros cheio também podem piorar ao longo do tempo. Registe qual recurso cresce e que operações deixam de funcionar primeiro. O facto de conexões duradouras sobreviverem enquanto as novas falham é uma prova útil, não um diagnóstico por si só.
Aumentar um limite tem um custo de memória. Antes de o alterar, determine a carga de trabalho, o namespace e a capacidade disponível. Encurtar os tempos limite sem critério pode quebrar sessões inativas úteis; limpar todo o estado das conexões pode perturbar tráfego não relacionado.
O resultado útil é uma explicação para a acumulação e uma alteração de capacidade ou de ciclo de vida que lhe corresponda. Seguro de aumentar não é uma propriedade que todos os servidores proxy partilham.