Ralentizacións do proxy co tempo: revisa conntrack e os límites de recursos
Investiga a presión do seguimento de conexións xunto cos límites do proxy e do host cando os fallos se acumulan co tempo.
O proxy responde despois dun reinicio. Unhas horas máis tarde, as conexións novas atascan. Reinicialo compra outro intervalo tranquilo. Ese patrón suxire un estado que se acumula, pero non identifica que estado é o responsable.
Nunha ruta Linux que usa seguimento de conexións, un candidato é a táboa conntrack. Comproba estes valores existentes na máquina e no espazo de nomes de rede que xestiona o tráfico:
/proc/sys/net/netfilter/nf_conntrack_count
/proc/sys/net/netfilter/nf_conntrack_maxO primeiro informa das entradas de fluxo asignadas; o segundo limítaas. Non son recontos de usuarios de Squid nin de peticións HTTP. O estado de fluxo do núcleo pode sobrevivir ao traballo activo da aplicación.
Busca unha relación, non só un número grande
Compara a ocupación ao longo do tempo coa aparición de fallos en conexións novas e coas mensaxes relevantes do núcleo. Un reconto alto sen probas de fallo correspondentes é distinto dunha táboa que acada o límite repetidamente xusto cando as peticións comezan a esgotar o tempo de espera.
A táboa pode servir a máis que o proxy. Outros servizos locais, o tráfico reenviado ou outra ruta de rede ocupada poden contribuír. Que reiniciar o proxy cambie o síntoma non demostra que a caché de obxectos de Squid fose a causa.
Mantén á vista as explicacións competidoras: descritores de ficheiro, colas dos axudantes de autenticación, atrasos de DNS, presión de memoria e un sistema de ficheiros cheo tamén poden empeorar co tempo. Anota que recurso medra e que operacións deixan de funcionar primeiro. Que as conexións de longa duración sobrevivan mentres as novas fallan é unha proba útil, non un diagnóstico por si só.
Subir un límite ten un custo de memoria. Antes de cambialo, establece a carga de traballo, o espazo de nomes e a capacidade dispoñible. Acortar os tempos de espera sen criterio pode romper sesións inactivas útiles; baleirar todo o estado de conexións pode interromper tráfico non relacionado.
O resultado útil é unha explicación da acumulación e un cambio de capacidade ou de ciclo de vida que encaixe con ela. Seguro de subir non é unha propiedade que comparta todo servidor proxy.