Je cours donc lsof -i | wc -lpériodiquement et ça me dit que sur 420 lignes, entre 240 et 255 sont en CLOSE_WAITétat. Comment les connexions TCP entrent-elles dans cet état?
Dois-je m'inquiéter et comment le résoudre?
7
(J'allais éditer la réponse de mikegrb, mais j'ai décidé de la boucher un peu trop)
CLOSE_WAIT signifie à peu près exactement ce qu'il dit - le noyau attend que le processus local ferme son descripteur de fichier avant de supprimer l'entrée. La connexion TCP a été complètement détruite et l'extrémité distante peut avoir l'impression que la connexion est finite, mais votre extrémité tient sur les choses.
Le seul problème est que beaucoup d'entrées CLOSE_WAIT consomment de la mémoire du noyau et des entrées de table de descripteur de fichier, ce qui peut être un problème s'il y en a beaucoup. Si les entrées que vous regardez sont transitoires, c'est probablement juste que vous parcourez beaucoupde connexions TCP, et vous en voyez une petite fraction dans le peu de temps entre la fermeture de la connexion et le processus de fermeture du descripteur de fichier. D'un autre côté, s'ils sont permanents (les ports et les adresses IP ne changent pas au fil du temps), alors quelque chose fuit des descripteurs et il doit être corrigé pour qu'il ferme toujours ses fichiers quand il en a fini avec eux. Comme l'a dit mikegrb, une version plus récente a peut-être déjà résolu le problème, donc une question sur la liste de diffusion ou l'examen des journaux des modifications est probablement justifié.
L'état CLOSE_WAIT signifie que l'autre extrémité a envoyé un segment FIN pour fermer la connexion. La connexion est toujours en quelque sorte établie. C'est dans un mode que vous pourriez considérer comme semi-duplex, permettant à cette extrémité de vider tous les tampons, d'envoyer les derniers bits de données à la fin en demandant la fermeture de la connexion avant de fermer la connexion à partir de cette extrémité.
Si vous avez beaucoup de connexions restant dans CLOSE_WAIT, cela signifie que le processus responsable ne ferme pas le socket une fois qu'il est entré dans CLOSE_WAIT. Vous pouvez utiliser tcpdump ou d'autres outils de capture du trafic réseau pour examiner les paquets.
Jetez également un œil au processus responsable. Par curiosité, quel est le processus responsable? Il peut avoir une version fixe plus récente disponible ou peut-être qu'il est temps de déposer un rapport de bogue;)
la source
si vous opérez dans un réseau faible, vous pouvez régler:
ulimitset via/proc(à l'échelle du système)/procla source
Vous ne fermez probablement pas une ressource (descripteur de fichier, connexion réseau) quelque part dans une application qui s'exécute sur le serveur.
la source