Comment puis-je surveiller la longueur de la file d'attente d'acceptation?

J'ai une hypothèse: parfois les connexions TCP arrivent plus vite que mon serveur ne peut accept()les faire. Ils font la queue jusqu'à ce que la file d'attente déborde, puis il y a des problèmes.

Comment puis-je confirmer que cela se produit?

Puis-je surveiller la longueur de la file d'attente d'acceptation ou le nombre de débordements? Y a-t-il un comptoir exposé quelque part?

linux networking monitoring

— Phil Frost
source

Vous cherchez netstat.

— Satō Katsura

Pour autant que je sache, netstatne montre que les longueurs de file d'attente d'envoi et de réception, ce qui n'est pas la même que la file d'attente d'acceptation.

— Phil Frost

Oui, il n'est pas affiché par défaut. man netstat | less +/Flags

— Satō Katsura

Je ne sais pas comment ces indicateurs me disent la longueur de la file d'attente acceptée - en fait, netstatil ne semble pas du tout s'afficher Flagspour les connexions TCP. D'après un petit test, il semble que les connexions soient affichées comme ESTABLISHEDdans netstat, même si j'essaie d'ouvrir des connexions à un processus qui le fait listen()mais jamais accept().

— Phil Frost

À droite, en regardant les sources, il semble que ces drapeaux soient pour les sockets UNIX. Pour TCP, vous pouvez simplement compter SYN_RECV. Il n'y a pas d'autre file d'attente au-delà de cela. Je suppose que le noyau peut être informé d'une manière ou d'une autre de journaliser les paquets perdus en raison de trop de connexions semi-ouvertes, mais il y a plus de 10 ans depuis que j'ai envisagé la mise en réseau avec Linux, donc je ne sais pas comment faire. Sur une note latérale: vous n'attendez pas pour accept()faire son travail, vous attendez que les ACKs arrivent des hôtes se connectant pour terminer les connexions.

— Satō Katsura

Réponses:

Pour vérifier si votre file d'attente déborde, utilisez netstat ou nstat

[centos ~]$ nstat -az | grep -i listen
TcpExtListenOverflows           3518352            0.0
TcpExtListenDrops               3518388            0.0
TcpExtTCPFastOpenListenOverflow 0  0.0

[centos ~]$ netstat -s | grep -i LISTEN
    3518352 times the listen queue of a socket overflowed
    3518388 SYNs to LISTEN sockets dropped

Référence: https://perfchron.com/2015/12/26/investigating-linux-network-issues-with-netstat-and-nstat/

Pour surveiller la taille de vos files d'attente, utilisez la commande ss et recherchez les sockets SYN-RECV.

$ ss -n state syn-recv sport = :80 | wc -l
119

Référence: https://blog.cloudflare.com/syn-packet-handling-in-the-wild/

— lfmunoz
source

Sysdig fournira certaines de ces informations à la fin de chaque acceptappel système, comme queuelenargument. Il montre également la longueur de la file d'attente en tant que queuemax.

7598971 21:05:30.322229280 1 gunicorn (6451) < accept fd=13(<4t>127.0.0.1:45882->127.0.0.1:8003) tuple=127.0.0.1:45882->127.0.0.1:8003 queuepct=0 queuelen=0 queuemax=10

Pour autant que je sache, il ne fournit aucun mécanisme pour savoir exactement quand ou combien de fois la file d'attente a débordé. Et il serait fastidieux d'intégrer cela à une surveillance périodique par collectdou similaire.

— Phil Frost
source

Ce que vous recherchez est l'entrée en sortie de la commande sysctl -a en tant que telle :::

net.ipv4.tcp_max_sync_backlog = 4096

Dans l'exemple ci-dessus, l'arriéré des connexions d'état SYN est au maximum de 4096. Vous pouvez l'augmenter en fonction de la quantité de RAM de votre serveur. Je considère que le backlog de 32 Ko est un bon début pour le réglage de serveurs Web lourdement chargés.

Assurez-vous également que ce qui suit n'est PAS défini sur Un (1) ::

net.ipv4.tcp_abort_on_overflow = 0

Sinon, il abandonnera définitivement les paquets en cas de dépassement du retard.

Vous pouvez facilement vérifier via

"arriéré sysctl -a | egrep"

"débordement de sysctl -a | egrep"

De plus, vous pouvez trouver une étiquette "supprimée" sous le

"ifconfig -a"

sortie de la commande. Cela montre combien de paquets ont été supprimés pour chaque interface ainsi que d'autres données et erreurs, etc.

Pour la journalisation des paquets perdus, il y a un article de paywall sur RHEL 7 ::

https://access.redhat.com/solutions/1191593

Pour de plus amples recherches, vous pouvez lire:

http://veithen.io/2014/01/01/how-tcp-backlog-works-in-linux.html

Il indique ici selon le livre illustré de Steven TCP / IP:

«La limite de file d'attente s'applique à la somme de […] le nombre d'entrées dans la file d'attente de connexion incomplète […] et […] le nombre d'entrées dans la file d'attente de connexion terminée […].»

Par conséquent, déclare également que:

"La file d'attente de connexion terminée est presque toujours vide car lorsqu'une entrée est placée dans cette file d'attente, l'appel du serveur à accepter revient et le serveur retire la connexion terminée de la file d'attente."

La file d'attente d'acceptation peut donc sembler complètement vide et vous devrez régler votre serveur Web Apache (éventuellement dans ce cas) pour accepter plus rapidement les connexions placées dans la file d'attente "agrégat total".

— mkzia
source

Bien qu'il semble y avoir des informations utiles ici, je ne suis pas sûr que cela réponde à la question. Si je demande: «Quel est le plus grand nombre de personnes qui ont jamais été dans cet auditorium à un moment donné?», Et que vous pointez un panneau sur le mur qui donne la capacité maximale, vous n'avez pas répondu à la question.

— Scott

En effet, je recherche la longueur actuelle de la file d'attente, pas la longueur maximale de la file d'attente.

— Phil Frost

Ce devrait être tcp_max_syn_backlog, pas tcp_max_SYNC_backlog comme dans votre réponse

— DevilaN

Ouais ... et StackOverflow vous donne un message d'erreur retardé lorsque vous essayez de le changer: "Les modifications doivent contenir au moins 6 caractères; y a-t-il autre chose à améliorer dans ce post?"

— Aaron C. de Bruyn