Ralentissements du proxy au fil du temps : vérifier conntrack et les limites de ressources
Examinez la pression du suivi de connexions avec les limites du proxy et de l'hôte lorsque les pannes s'accumulent au fil du temps.
Le proxy répond après un redémarrage. Quelques heures plus tard, les nouvelles connexions se bloquent. Un nouveau redémarrage achète un autre intervalle calme. Ce schéma suggère un état qui s'accumule, mais il n'indique pas quel état en est responsable.
Sur un chemin Linux qui utilise le suivi de connexions, un candidat est la table conntrack. Vérifiez ces valeurs existantes sur la machine et dans l'espace de noms réseau qui traite le trafic :
/proc/sys/net/netfilter/nf_conntrack_count
/proc/sys/net/netfilter/nf_conntrack_maxLa première indique les entrées de flux allouées ; la seconde les limite. Ce ne sont pas des comptages d'utilisateurs Squid ni de requêtes HTTP. L'état de flux du noyau peut survivre au travail actif de l'application.
Cherchez une relation, pas seulement un grand nombre
Comparez l'occupation au fil du temps avec l'apparition des échecs de nouvelles connexions et avec les messages pertinents du noyau. Un compte élevé sans preuve d'échec correspondante diffère d'une table qui atteint à plusieurs reprises sa limite juste au moment où les requêtes commencent à expirer.
La table peut servir plus que le proxy. D'autres services locaux, du trafic transféré ou un autre chemin réseau chargé peuvent y contribuer. Le fait qu'un redémarrage du proxy modifie le symptôme ne prouve pas que le cache d'objets de Squid en soit la cause.
Gardez les explications concurrentes en vue : descripteurs de fichiers, files d'attente des assistants d'authentification, délais DNS, pression mémoire et système de fichiers plein peuvent aussi se dégrader au fil du temps. Notez quelle ressource croît et quelles opérations cessent de fonctionner en premier. Le fait que des connexions de longue durée survivent alors que les nouvelles échouent est une preuve utile, pas un diagnostic à lui seul.
Relever une limite a un coût en mémoire. Avant de la modifier, établissez la charge de travail, l'espace de noms et la capacité disponible. Raccourcir les délais sans discernement peut casser des sessions inactives utiles ; vider tout l'état des connexions peut perturber du trafic sans rapport.
Le résultat utile est une explication de l'accumulation et un changement de capacité ou de cycle de vie qui lui correspond. Sûr à augmenter n'est pas une propriété que partage chaque serveur proxy.