Comment ne PAS obtenir autant de connexions apache CLOSE_WAIT?

netstat montre qu'il y a 153 connexions sur l'état CLOSE_WAIT. Les connexions ne sont jamais fermées. Ainsi, les heures supplémentaires, le serveur est rempli de ces connexions qui remplissent la RAM et maintenant les sites Web ne se chargent pas.

netstat en montre beaucoup comme les suivants:

tcp      160      0 my_server_name:http         my_server_name:51584        CLOSE_WAIT
tcp      160      0 my_server_name:http         my_server_name:51586        CLOSE_WAIT
tcp        0      0 my_server_name:http         my_server_name:50827        CLOSE_WAIT
tcp        0      0 my_server_name:http         my_server_name:50830        CLOSE_WAIT
tcp      312      0 my_server_ip.static.:http rate-limited-proxy-72:61249 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:58663 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:34655 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:56681 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:40829 CLOSE_WAIT
tcp      576      0 my_server_ip.static.:http b3090792.crawl.yahoo.:38278 CLOSE_WAIT
tcp       47      0 my_server_ip.static.:http 203.200.5.143.ill-bgl:49379 CLOSE_WAIT

Si je regarde le journal des erreurs appache, avant que la situation CLOSE_WAIT ne survienne, il y a des lignes comme les suivantes

[warn] child process 15670 still did not exit, sending a SIGTERM
[error] child process 15670 still did not exit, sending a SIGKILL
[notice] child pid 3511 exit signal Segmentation fault (11)

Ma configuration Apache 2.2.3 RAM 1024 Mo (rafale 2048 Mo) CentOS version 5.3 (finale) exécutant 2 installations WPMU 2.9.2

Contexte

Le socket entre dans l'état CLOSE_WAIT lorsque l'extrémité distante met fin à la connexion en envoyant un paquet avec l'indicateur FIN défini. Il attend ensuite dans cet état l'application locale au close()socket, puis envoie sa propre FIN au client et fait passer le socket à l'état LAST_ACK. Voir également le diagramme de transition d'état TCP et RFC 793 .

Notez également que CLOSE_WAIT n'est pas lié au tristement célèbre TIME_WAIT puisque le premier se produit sur la branche de fermeture passive (l'extrémité distante se ferme en premier) tandis que le dernier sur la branche de fermeture active (l'extrémité locale se ferme en premier).

Description du problème

Normalement, les connexions passent de CLOSE_WAIT à LAST_ASK assez rapidement. Si l'adresse et le port distants continuent de changer rapidement, un bon nombre de connexions dans l'état CLOSE_WAIT peuvent simplement être la conséquence d'un très grand nombre de connexions ouvertes, utilisées et fermées. Les performances du système doivent être examinées, mais en soi, cela ne constitue pas un problème.

Si l'adresse distante et le port changent lentement, cela indique que les processus d'application doivent attendre le CPU, auquel cas des moyennes de charge élevées le confirmeront.

Si, en revanche, l'adresse et le port distants restent constants et que le nombre de connexions dans l'état CLOSE_WAIT continue d'augmenter, cela indique très probablement un problème avec l'application. Il s'agit d'un cas particulier du bogue de fuite de ressources: l'application laisse échapper des sockets ouverts au lieu de les fermer en temps opportun. Cela consomme de la mémoire du noyau et fera éventuellement échouer l'application une fois qu'elle aura atteint le nombre maximal de descripteurs de fichiers ouverts.

Notez cependant que le rythme de la fuite peut être lent. Il arrive souvent que des bogues comme celui-ci résultent d'une incapacité à gérer une exception au milieu d'une demande, interrompant le flux d'exécution dans un thread de travail, ce qui peut empêcher le nettoyage (y compris la fermeture de socket). L'exception fautive peut survenir rarement.

Solution temporaire

La solution temporaire au problème consiste à augmenter les limites des descripteurs de fichiers ouverts et à redémarrer périodiquement l'application lorsque (de préférence avant) le problème commence à affecter les performances. Notez que cela peut impacter par inadvertance les connexions actuellement ouvertes. L'existence de serveurs redondants et l'équilibrage de charge peuvent aider à masquer le problème aux utilisateurs.

Solution permanente

La solution permanente au problème consiste à déployer la version de l'application sans le bogue. La mesure dans laquelle la solution temporaire nuit aux utilisateurs et à l'entreprise, l'état de préparation de la version corrigée et l'état de la dernière version de travail permettent de décider de revenir à la dernière version de travail de l'application ou d'attendre le correctif.