Quelle est la formule pour déterminer la quantité de mémoire consommée par un socket sous Linux?

Je fais un peu de planification de capacité et je me demandais s'il y avait une formule que je pouvais utiliser pour prédire (du point de vue de la mémoire) combien de connexions TCP je pouvais gérer sur mon serveur. Pour le moment, je ne me préoccupe que des besoins en mémoire.

Je pense que certaines variables apparaîtront dans la formule:

• sysctl's net.ipv4.tcp_wmem(min ou valeur par défaut)
• sysctl's net.ipv4.tcp_rmem(min ou valeur par défaut)
• la taille des structures de données sock, sock_common, proto et autres par socket.

Je ne sais pas combien de tcp_wmem et tcp_rmem sont réellement alloués et quand cette mémoire est allouée. Au moment de la création du socket? À la demande?

Si vous pouvez modifier le code source, utilisez les données de rusage pour mesurer le RSS et enregistrez le nombre de connexions TCP en jeu au moment de la mesure.

Si le code source ne peut pas être modifié, utilisez le RSS de l'application réseau tel que rapporté par top ou ps et obtenez le nombre de connexions réseau au moment de la mesure lsof -i.

Collectez ces données toutes les minutes pendant que votre application passe par une charge de pointe, et à partir de ces données, vous pouvez trouver une formule qui relie le nombre de connexions à l'utilisation de la RAM.

Bien sûr, il y a beaucoup plus de choses que vous pourriez mesurer, en particulier vous voudrez peut-être mesurer l'utilisation de la RAM du noyau, bien que les structures de données TCP devraient être prévisibles et calculables à l'avance. Dans tous les cas, jetez un œil à cette question /server/10852/what-limits-the-maximum-number-of-connections-on-a-linux-server pour plus d'informations sur le réglage TCP et comment obtenir une vision claire de ce qui se passe dans la pile réseau.

tcp_mem est plus important car il définit le comportement de la pile tcp en matière d'utilisation de la mémoire. Le tampon d'envoi et de réception de l'OMI doit être un multiple de tcp_mem. Voici un lien vers une formule pour le tampon de réception: http://www.acc.umu.se/~maswan/linux-netperf.txt . En bref:

La surcharge est: window / 2 ^ tcp_adv_win_scale (tcp_adv_win_scale par défaut est 2) Donc pour les paramètres par défaut de linux pour la fenêtre de réception (tcp_rmem): 87380 - (87380/2 ^ 2) = 65536. Étant donné un lien transatlantique (150 ms RTT), les performances maximales finissent par: 65536 / 0,150 = 436906 octets / s ou environ 400 kilo-octets / s, ce qui est vraiment lent aujourd'hui. Avec la taille par défaut augmentée: (873800 - 873800/2 ^ 2) /0.150 = 4369000 octets / s, soit environ 4 Moctets / s, ce qui résonne pour un réseau moderne. Et notez qu'il s'agit de la valeur par défaut, si l'expéditeur est configuré avec une taille de fenêtre plus grande, il évoluera volontiers jusqu'à 10 fois (8738000 * 0,75 / 0,150 = ~ 40 Mo / s), assez bon pour un réseau moderne.

Voici ce que l'article dit sur tcp_mem:

Ce que vous supprimez est une limite artificielle aux performances TCP, sans cette limite, vous êtes limité par la bande passante et la perte de bout en bout disponibles. Donc, vous pourriez finir par saturer votre liaison montante plus efficacement, mais TCP est bon pour gérer cela.

IMO une valeur tcp_mem moyenne plus grande accélère la connexion à la perte de moins de sécurité et augmente légèrement l'utilisation de la mémoire.

Vous pouvez surveiller la pile réseau avec:

grep skbuff /proc/slabinfo

David a fourni une très bonne réponse à la question posée, mais à moins que vous n'utilisiez exclusivement des LFN , même sur un serveur basé sur des événements, les tampons TCP ne constitueront probablement qu'une petite partie de l'empreinte par connexion.

Pour la planification de la capacité, rien ne peut remplacer le test du serveur et le calcul de la régression de l'utilisation de la mémoire par charge.