Structure de socket du noyau et TCP_DIAG

Je travaille sur un logiciel qui se connecte à un serveur de données en temps réel (en utilisant TCP) et j'ai quelques connexions qui tombent. Je suppose que les clients ne lisent pas assez rapidement les données provenant du serveur. Par conséquent, je voudrais surveiller mes sockets TCP. Pour cela j'ai trouvé l'outil "ss".

Cet outil permet de voir l'état de chaque socket - voici un exemple de ligne de sortie de la commande ss -inm 'src *:50000'

ESTAB      0      0             184.7.60.2:50000       184.92.35.104:1105
  mem:(r0,w0,f0,t0) sack rto:204 rtt:1.875/0.75 ato:40

Ma question est: que signifie la partie mémoire? En regardant le code source de l'outil, j'ai constaté que les données proviennent d'une structure de noyau ( socken sock.h). Plus précisément, il provient des domaines:

r = sk->sk_rmem_alloc
w = sk->sk_wmem_queued;
f = sk->sk_forward_alloc;
t = sk->sk_wmem_alloc;

Quelqu'un sait-il ce qu'il veut dire? Mes suppositions sont:

rmem_alloc : taille du tampon entrant
wmem_alloc : taille du tampon sortant
sk_forward_alloc : ???
sk->sk_wmem_queued : ???

Voici mes tailles de tampons:

net.ipv4.tcp_rmem = 4096        87380   174760
net.ipv4.tcp_wmem = 4096        16384   131072
net.ipv4.tcp_mem = 786432       1048576 1572864
net.core.rmem_default = 110592
net.core.wmem_default = 110592
net.core.rmem_max = 1048576
net.core.wmem_max = 131071

linux tcp socket Tornade
la source

Quelle est votre configuration de taille de tampon? Voyez-vous des tampons de réception saturés sur les connexions de socket? Votre parti abandonne-t-il sa connexion sur EWOULDBLOCK?

Karlson

Mes tailles de prises sont assez petites je pense, j'ai mis à jour le post avec elles. Pour le EWOULDBLOCK, je ne peux pas le dire. Mon client est en JAVA et dis simplement qu'il a été déconnecté par le serveur. Le serveur est en C ++ et il vient de dire qu'il a abandonné la connexion sans aucune information. Je n'ai pas le code source du serveur donc je ne peux pas changer son comportement. Il semble que les clients se déconnectent lorsqu'ils sont un peu surchargés, même si cela ne dure que quelques secondes.

Twister

La configuration des tailles de tampons est-elle réglable sur le serveur? Pouvez-vous regarder la taille des tampons sur le client? Avez-vous accès à la source du client? Avez-vous exécuté netstat -apnc pour surveiller les tailles de tampon? Avez-vous essayé d'augmenter la taille des tampons dans le noyau pour voir ce qui se passe?

Karlson

Oui, ils le sont et sont déjà définis sur la valeur maximale du serveur (je pense qu'ils ne peuvent pas être plus grands que les propriétés net.ipv4.tcp_ *, non?) Pour netstat -apnc, cela ne me donne pas la taille des tampons, c'est pourquoi j'ai examiné les art. Pour le noyau, je ne suis pas root sur le serveur, et les équipes informatiques sont plutôt têtues. Je dois être sûr de ce qui se passe avant de leur demander de changer les valeurs ... Et oui j'ai accès à la source client, et mon enquête sur le client confirme que la déconnexion vient du serveur.

Twister

netstat -apnc vous donne la taille totale des files d'attente d'envoi et de réception sur Linux. Si le serveur définit le tampon au maximum disponible et que vous saturez toujours, vous avez peut-être besoin de paramètres de tampon plus élevés au niveau du système d'exploitation

Karlson

Réponses:

sk_forward_alloc est la mémoire allouée vers l'avant qui est la mémoire totale actuellement disponible dans le quota du socket.

sk_wmem_queued est la quantité de mémoire utilisée par le tampon d'envoi de socket en file d'attente dans la file d'attente de transmission et qui n'est pas encore envoyée ou pas encore acquittée.

Vous pouvez en savoir plus sur la gestion de la mémoire TCP dans le chapitre 9 de l'architecture, la conception et la mise en œuvre TCP / IP sous Linux par Sameer Seth, M. Ajaykumar Venkatesulu

aculich
la source

Je ne comprends pas en quoi cette définition de sk_wmem_queueddiffère de sk_wmem_alloc, pourriez-vous développer un peu ce point? (Si vous connaissez la réponse, n'hésitez pas à ajouter une réponse à cette question: unix.stackexchange.com/questions/551444/… )

petit-mec

Voir la page de manuel des art.

<fwd_alloc>
   The  memory allocated by the socket as cache, but not used for receiving/sending packet yet. If need memory to send/receive packet, the memory in this cache will be used before allocate additional memory.

<wmem_queued>
   The memory allocated for sending packet (which has not been sent to layer 3)

wenjianhn
la source

En ce qui concerne sk_wmem_queued et sk_wmem_alloc, j'ai posé la même question donc je vais copier la réponse ici:

J'ai envoyé un e-mail à Eric Dumazet, qui contribue à la pile réseau Linux, et voici la réponse:

sk_wmem_allocsuit le nombre d'octets pour skb mis en file d'attente après la pile de transport: couche qdisc et tampons en anneau NIC TX.

Si vous avez 1 Mo de données dans la file d'attente d'écriture TCP, pas encore envoyé (limite cwnd), sk_wmem_queue sera environ 1 Mo, mais sk_wmem_allocenviron 0

Un très bon document pour comprendre ce que sont ces trois types de files d'attente (tampon de socket, file d'attente qdisc et file d'attente de périphériques) est cet article (plutôt long) . En résumé, le socket commence par pousser les paquets directement dans la file d'attente qdisc, qui les transmet à la file d'attente des périphériques. Lorsque la file d'attente qdisc est pleine, le socket commence la mise en mémoire tampon des données dans sa propre file d'attente d'écriture.

la pile réseau place les paquets directement dans la discipline de mise en file d'attente ou repousse les couches supérieures (par exemple, tampon de socket) si la file d'attente est pleine

Donc, fondamentalement: sk_wmem_queuesest la mémoire utilisée par le tampon de socket ( sock.sk_write_queue) tandis que sk_wmem_allocla mémoire est utilisée par les paquets dans les files d'attente qdisc et device.

petit mec
la source