Des tonnes de connexions TCP dans l'état TIME_WAIT sur Windows 2008 - en cours d'exécution sur Amazon AWS

Système d'exploitation: Windows Server 2008, SP2 (fonctionnant sur EC2 Amazon).

L'exécution de l'application Web à l'aide du serveur Apache httpd et tomcat 6.02 et du serveur Web a des paramètres persistants.

Il y a environ 69 250 (port http 80) + 15 000 (autres que le port 80) connexions TCP dans l'état TIME_WAIT (utilisé netstat & tcpview). Ces connexions ne semblent pas se fermer même après l'arrêt du serveur Web (attendu 24 heures)

Compteurs de moniteur de performances:

• Connexions actives TCPv4: 145 Ko
• Connexions passives TCPv4: 475 Ko
• Connexions d'échec TCPv4: 16K
• Réinitialisation des connexions TCPv4: 23K

HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters n'a pas de clé TcpTimedWaitDelay, donc la valeur doit être la valeur par défaut (2 * MSL, 4 minutes)

Même s'il y a des milliers de demandes de connexion qui arrivent en même temps, pourquoi le système d'exploitation Windows n'est-il pas en mesure de les nettoyer finalement?
Quelles pourraient être les raisons de cette situation?
Existe-t-il un moyen de fermer de force toutes ces connexions TIME_WAIT sans redémarrer le système d'exploitation Windows?

Après quelques jours, l'application cesse de prendre de nouvelles connexions.

Nous avons également traité de cette question. Il semble qu'Amazon ait trouvé la cause première et l'a corrigée. Voici les informations qu'ils m'ont données.

Bonjour, je colle ci-dessous une explication de la cause de ce problème. La bonne nouvelle est que cela a été corrigé très récemment par notre équipe d'ingénieurs. Pour résoudre ce problème, il vous suffit d'arrêter / de démarrer les instances de Windows Server 2008 où vous rencontrez ce problème. Encore une fois, je ne parle pas de REBOOT qui est différent. STOP / START provoque le déplacement de l'instance vers un hôte différent (sain). Lorsque ces instances seront relancées, elles s'exécuteront sur des hôtes qui ont le correctif en place afin de ne plus avoir ce problème. Vous trouverez ci-dessous l'explication technique de ce problème. Après une enquête approfondie, nous avons constaté que lors de l'exécution de Windows 2008 x64 sur la plupart des types d'instances disponibles, nous ' Nous avons identifié un problème pouvant entraîner des connexions TCP qui restent dans TIME_WAIT / CLOSE_WAIT pendant des périodes excessivement longues (dans certains cas, restent indéfiniment dans cet état). Alors que dans ces états, les paires de sockets particulières restent inutilisables et si suffisamment s'accumulent, entraînera l'épuisement des ports pour les ports en question. Si cette circonstance particulière se produit, la seule solution pour effacer les paires de sockets en question est de redémarrer l'instance en question. Nous avons déterminé la cause des valeurs produites par une fonction de minuterie dans l'API du noyau Windows 2008 qui, sur bon nombre de nos plates-formes 64 bits, récupérera occasionnellement une valeur extrêmement éloignée à l'avenir. Cela affecte la pile TCP en provoquant un horodatage significatif des horodatages sur les paires de sockets TCP à l'avenir. Selon Microsoft, il existe un compteur cumulatif stocké qui ne sera mis à jour que si la valeur produite par cet appel d'API est supérieure à la valeur cumulée. Le résultat final est que les sockets créées après ce point seront toutes estampées trop loin dans le futur jusqu'à ce que cette heure future soit atteinte. Dans certains cas, nous avons vu cette valeur plusieurs centaines de jours dans le futur, ainsi les paires de prises semblent être bloquées pour toujours.

La réponse de Ryan est un bon conseil général, sauf qu'il ne s'applique pas à la condition que Ravi connaît dans EC2. Nous avons également vu ce problème et pour une raison quelconque, Windows ignore complètement le TcpTimedWaitDelay et ne libère jamais le socket de son état TIMED_WAIT.

Attendre n'aide pas ... redémarrer l'application n'aide pas ... le seul remède que nous avons trouvé est de redémarrer le système d'exploitation. Vraiment moche.

J'ai trouvé ce fil de façon complètement aléatoire en cherchant à déboguer un problème distinct, mais c'est un problème peu connu mais bien connu avec Windows sur EC2. Nous avons déjà eu le soutien de la prime, et discuté avec eux dans un cadre non-public via ce canal, mais c'est une question connexe que nous ne discutons dans les forums publics .

Comme d'autres l'ont mentionné, vous devez régler les serveurs Windows hors de la boîte. Cependant, de la même manière que StopWatch ne fonctionne pas dans le thread ci-dessus, la pile TCP / IP utilise également l' QueryPerformanceCounterappel pour déterminer exactement quand la période TCP_TIME_WAIT doit durer. Le problème est que sur EC2, ils ont rencontré et connaissent un problème dans lequel QueryPerformanceCounterse détraque et peut revenir des temps très loin dans le futur; ce n'est pas que votre état TIME_WAIT est ignoré, c'est que le délai d'expiration de TIME_WAIT est potentiellement des années dans le futur. Lorsque vous exécutez dans un paramètre httpd, vous pouvez voir comment vous accumulez rapidement ces sockets zombies une fois que l'état est rencontré (nous constatons généralement qu'il s'agit d'un événement discret, pas que vous accumulez lentement des zombies).

Ce que nous faisons est d'exécuter un service en arrière-plan qui interroge le nombre de sockets dans l'état TIME_WAIT, et une fois que celui-ci dépasse un certain seuil, nous prenons des mesures (redémarrez le serveur). Quelque part au cours des 45 dernières secondes , quelqu'un a souligné que vous pouvez arrêter / démarrer le serveur pour résoudre le problème - je vous suggère de coupler ces deux approches.

Les paramètres par défaut de la pile TCP dans Windows ne sont pour le moins pas optimaux pour les systèmes qui vont héberger un serveur HTTP.

Pour tirer le meilleur parti de votre machine Windows lorsqu'elle est utilisée en tant que serveur HTTP, il y a quelques paramètres que vous devriez normalement modifier comme MaxUserPort TcpTimedWaitDelay, TcpAckFrequency, EnableDynamicBacklog, KeepAliveInterval, etc.

J'avais écrit une note à ce sujet il y a quelques années, juste au cas où j'aurais besoin de quelques défauts par défaut pour commencer. N'hésitez pas à comprendre les paramètres puis à les modifier.

Sans rapport avec AWS, nous venons de rencontrer ce problème, il semble à la suite de cet article de la base de connaissances:

http://support.microsoft.com/kb/2553549/en-us

Fondamentalement, il se déclenche si un système est opérationnel pendant> 497 jours et que le correctif n'a pas été appliqué. Un redémarrage l'a bien sûr effacé - nous ne saurons peut-être pas pendant 16 mois si le correctif a fonctionné, mais cela peut aider toute personne disposant de serveurs à longue disponibilité.

Je vivais la même chose presque exacte sur un certain nombre de boîtes avec Windows Server 2008 R2 x64 avec SP1, principalement avec CLOSE_WAIT (qui est quelque peu différent de TIME_WAIT). Je suis tombé sur cette réponse qui faisait référence à une base de connaissances chez Microsoft et à un correctif si les serveurs fonctionnaient derrière un équilibreur de charge (qui sont les miens). Après avoir installé le correctif et redémarré, tous les problèmes CLOSE_WAIT ont été résolus.