comment vérifier la taille de l'anneau rx, max_backlog et max_syn_backlog


41

Très souvent, au cours de la résolution de problèmes et de la mise au point de solutions, je suis amené à penser aux paramètres de noyau Linux suivants:

net.core.netdev_max_backlog
net.ipv4.tcp_max_syn_backlog
net.core.somaxconn

Autre que fs.file-max, net.ipv4.ip_local_port_range, net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmemet net.ipv4.tcp_wmem, ils semblent être les boutons importants au mess avec lorsque vous accordez une boîte pour les niveaux élevés de concurrence.

Ma question: Comment puis-je vérifier le nombre d'éléments contenus dans chacune de ces files d'attente? Habituellement, les utilisateurs se contentent de les définir très haut, mais je voudrais enregistrer ces tailles de file d'attente pour aider à prévoir les futurs échecs et résoudre les problèmes avant qu'ils ne se manifestent de manière perceptible par l'utilisateur.


C'est une question géniale. Je m'intéresse au problème de la diffusion et de la retransmission TCP haute résolution.
dhchdhd

Réponses:


29

Moi aussi je me suis demandé cela et j'ai été motivé par votre question!

J'ai rassemblé à quel point je pouvais me rapprocher de chacune des files d'attente que vous avez énumérées avec des informations relatives à chacune d'elles. Je souhaite la bienvenue aux commentaires / réactions, toute amélioration apportée à la surveillance simplifie la gestion!

net.core.somaxconn

net.ipv4.tcp_max_syn_backlog

net.core.netdev_max_backlog

$ netstat -an | grep -c SYN_RECV 

Affiche le nombre total actuel de connexions dans la file d'attente. Vous pouvez le décomposer par port et l'insérer dans les instructions exec dans le fichier snmpd.conf si vous souhaitez l'interroger à partir d'une application de surveillance.

De:

netstat -s

Celles-ci vous montreront à quelle fréquence vous voyez les demandes de la file d'attente:

146533724 packets directly received from backlog
TCPBacklogDrop: 1029
3805 packets collapsed in receive queue due to low socket buffer

fs.file-max

De:

http://linux.die.net/man/5/proc

$ cat /proc/sys/fs/file-nr
2720    0       197774

Ce fichier (en lecture seule) donne le nombre de fichiers actuellement ouverts. Il contient trois chiffres: le nombre de descripteurs de fichiers alloués, le nombre de descripteurs de fichiers libres et le nombre maximal de descripteurs de fichiers.

net.ipv4.ip_local_port_range

Si vous pouvez créer une liste d'exclusion de services (netstat -an | grep LISTEN), vous pouvez en déduire le nombre de connexions utilisées pour une activité éphémère:

netstat -an | egrep -v "MYIP.(PORTS|IN|LISTEN)"  | wc -l

Devrait également surveiller (depuis SNMP):

TCP-MIB::tcpCurrEstab.0

Il peut également être intéressant de collecter des statistiques sur tous les états vus dans cet arbre (établi / time_wait / fin_wait / etc):

TCP-MIB::tcpConnState.*

net.core.rmem_max

net.core.wmem_max

Vous devriez dtrace / strace votre système pour les requêtes setsockopt. Je ne pense pas que les statistiques pour ces demandes soient suivies autrement. Ce n'est pas vraiment une valeur qui change de ma compréhension. L'application que vous avez déployée demandera probablement un montant standard. Je pense que vous pouvez «profiler» votre application avec strace et configurer cette valeur en conséquence. (discuter?)

net.ipv4.tcp_rmem

net.ipv4.tcp_wmem

Pour savoir si vous êtes proche de la limite, vous devez consulter les valeurs moyenne et maximale des champs tx_queue et rx_queue à partir de (régulièrement):

# cat /proc/net/tcp
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                                                     
   0: 00000000:0FB1 00000000:0000 0A 00000000:00000000 00:00000000 00000000   500        0 262030037 1 ffff810759630d80 3000 0 0 2 -1                
   1: 00000000:A133 00000000:0000 0A 00000000:00000000 00:00000000 00000000   500        0 262029925 1 ffff81076d1958c0 3000 0 0 2 -1                

Pour suivre les erreurs liées à ceci:

# netstat -s
    40 packets pruned from receive queue because of socket buffer overrun

Devrait également surveiller le pool 'tampon' global (via SNMP):

HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: Memory Buffers
HOST-RESOURCES-MIB::hrStorageSize.1 = INTEGER: 74172456
HOST-RESOURCES-MIB::hrStorageUsed.1 = INTEGER: 51629704

2

Je pense que vous pourrez peut-être obtenir ces données avec SystemTap. Voici le manuel de référence Redhat (pdf) . Il existe également un guide du débutant (pdf) .

L’outil semble assez polyvalent pour vous permettre d’obtenir ces données, en particulier, cela probe::netdev.rxressemble à quelque chose qui vous donnera des informations sur les entrées entrantes; maintenant, vous devez seulement trouver la taille nette de la file d’attente dans la mémoire tampon ou quelque chose qui compte quitter la file d'attente…

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.