53 votes

L'augmentation de net.core.somaxconn fera-t-elle une différence ?

J'ai eu une discussion sur le paramètre net.core.somaxconn : On m'a dit que cela ne ferait aucune différence si nous changions la valeur par défaut 128.

J'ai pensé que cela pourrait être une preuve suffisante :

"Si l'argument backlog est supérieur à la valeur de /proc/sys/net/core/somaxconn, il est silencieusement tronqué à cette valeur. http://linux.die.net/man/2/listen

mais ce n'est pas le cas.

Quelqu'un connaît-il une méthode permettant de le vérifier avec deux machines installées sur un réseau Gbit ? Le mieux serait d'utiliser MySQL, LVS, apache2 ( 2.2 ), memcached.

79voto

Toby Allen Points 6734

Paramètres net.core.somaxconn à des valeurs plus élevées n'est nécessaire que sur les serveurs très chargés où le taux de nouvelles connexions est si élevé qu'une valeur de 128 (50 % de plus dans BSD : 128 backlog + 64 half-open ) des connexions non encore acceptées est considérée comme normale. Ou lorsque vous devez déléguer la définition de "normal" à une application elle-même.

Certains administrateurs utilisent des net.core.somaxconn pour dissimuler les problèmes liés à leurs services, de sorte que, du point de vue de l'utilisateur, le processus ressemblera à un pic de latence au lieu d'une connexion interrompue ou d'un dépassement de délai (contrôlé par la fonction net.ipv4.tcp_abort_on_overflow sous Linux).

listen(2) manuel dit - net.core.somaxconn agit comme la seule limite supérieure pour une application qui est libre de choisir quelque chose de plus petit (généralement défini dans la configuration de l'application). Bien que certaines applications utilisent simplement listen(fd, -1) ce qui signifie que le carnet de commandes est réglé sur la valeur maximale autorisée par le système.

La cause réelle est soit un faible taux de traitement (par exemple, un serveur bloqué à un seul thread), soit un nombre insuffisant de threads/processus de travail (par exemple, un logiciel bloqué à plusieurs processus/threads tel que apache / tomcat )

PS. Il est parfois préférable d'échouer rapidement et de laisser l'équilibreur de charge faire son travail (réessayer) plutôt que de faire attendre l'utilisateur. net.core.somaxconn n'importe quelle valeur, et limiter l'arriéré de demandes à par exemple 10 et définir net.ipv4.tcp_abort_on_overflow à 1.

PPS. Les anciennes versions du noyau Linux ont le vilain défaut de tronquer les mots de passe. somaxcon sur ses 16 bits inférieurs (c.-à-d. la valeur de coulée sur uint16_t ), de sorte que l'augmentation de cette valeur à plus de 65535 peut même être dangereuse. Pour plus d'informations, voir http://patchwork.ozlabs.org/patch/255460/

Si vous souhaitez entrer dans les détails de tous les aspects internes de l'arriéré sous Linux, n'hésitez pas à lire ce qui suit : Fonctionnement de l'arriéré TCP sous Linux .

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X