web-dev-qa-db-fra.com

Comment réduire le nombre de sockets dans TIME_WAIT?

Ubuntu Server 10.04.1 x86

J'ai une machine avec un service HTTP FCGI derrière nginx, qui sert de nombreuses petites requêtes HTTP à de nombreux clients différents. (Environ 230 demandes par seconde aux heures de pointe, la taille moyenne des réponses avec en-têtes est de 650 octets, plusieurs millions de clients différents par jour.)

En conséquence, j'ai beaucoup de sockets, suspendus dans TIME_WAIT (le graphique est capturé avec TCP ci-dessous):

TIME_WAIT

Je voudrais réduire le nombre de sockets.

Que puis-je faire en plus de cela?

. ] $ cat /proc/sys/net/ipv4/tcp_tw_reuse[.____. E5E1

Mise à jour: quelques détails sur la configuration réelle du service sur la machine:

 client ----- TCP-socket -> nginx (proxy inverse d'équilibrage de charge) 
 ----- TCP-socket -> nginx (travailleur) 
 - -domain-socket -> fcgi-software 
 --single-persistent-TCP-socket -> Redis 
 --single-persistent-TCP-socket -> MySQL (autre machine)

Je devrais probablement changer d'équilibreur de charge -> connexion du travailleur aux sockets de domaine également, mais le problème concernant les sockets TIME_WAIT resterait - je prévois d'ajouter bientôt un deuxième travailleur sur une machine distincte. Ne pourra pas utiliser les sockets de domaine dans ce cas.

ubuntunginxlinux-networkinghigh-load
36
Alexander Gladysh

Une chose que vous devez faire pour commencer est de corriger le net.ipv4.tcp_fin_timeout=1. C'est bien trop bas, vous ne devriez probablement pas prendre beaucoup moins que 30.

Puisque c'est derrière nginx. Cela signifie-t-il que nginx agit comme un proxy inverse? Si tel est le cas, vos connexions sont 2x (une vers le client, une vers vos serveurs Web). Savez-vous à quelle extrémité ces prises appartiennent?

Mise à jour:
fin_timeout est la durée pendant laquelle ils restent dans FIN-WAIT-2 (De networking/ip-sysctl.txt dans la documentation du noyau):

tcp_fin_timeout - INTEGER
        Time to hold socket in state FIN-WAIT-2, if it was closed
        by our side. Peer can be broken and never close its side,
        or even died unexpectedly. Default value is 60sec.
        Usual value used in 2.2 was 180 seconds, you may restore
        it, but remember that if your machine is even underloaded WEB server,
        you risk to overflow memory with kilotons of dead sockets,
        FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1,
        because they eat maximum 1.5K of memory, but they tend
        to live longer. Cf. tcp_max_orphans.

Je pense que vous devrez peut-être simplement laisser Linux garder le numéro de socket TIME_WAIT par rapport à ce qui ressemble peut-être à un plafond de 32 Ko et c'est là que Linux les recycle. Ce 32k est évoqué dans ce lien :

De plus, je trouve le/proc/sys/net/ipv4/tcp_max_tw_buckets déroutant. Bien que la valeur par défaut soit fixée à 180000, je constate une interruption TCP lorsque j'ai 32 sockets TIME_WAIT sur mon système, quel que soit le nombre maximal de tw twets.

Ce lien suggère également que l'état TIME_WAIT est de 60 secondes et ne peut pas être réglé via proc.

Fait amusant au hasard:
Vous pouvez voir les temporisateurs sur le timewait avec netstat pour chaque socket avec netstat -on | grep TIME_WAIT | less

Réutiliser Vs Recycle:
Celles-ci sont plutôt intéressantes, elles se lisent comme la réutilisation permet la réutilisation des sockets time_Wait, et le recyclage le met en mode TURBO:

tcp_tw_recycle - BOOLEAN
        Enable fast recycling TIME-WAIT sockets. Default value is 0.
        It should not be changed without advice/request of technical
        experts.

tcp_tw_reuse - BOOLEAN
        Allow to reuse TIME-WAIT sockets for new connections when it is
        safe from protocol viewpoint. Default value is 0.
        It should not be changed without advice/request of technical
        experts.

Je ne recommanderais pas d'utiliser net.ipv4.tcp_tw_recycle car cela pose des problèmes avec NAT clients .

Peut-être pourriez-vous essayer de ne pas allumer les deux et voir quel effet cela a (essayez un à la fois et voyez comment ils fonctionnent par eux-mêmes)? J'utiliserais netstat -n | grep TIME_WAIT | wc -l pour un retour plus rapide que Munin.

29
Kyle Brandt

tcp_tw_reuse est relativement sûr car il permet de réutiliser les connexions TIME_WAIT.

Vous pouvez également exécuter plus de services en écoutant sur différents ports derrière votre équilibreur de charge si le manque de ports est un problème.

2
andrew pate