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

Je suis entré dans un argument sur le paramètre net.core.somaxconn: on m'a dit que cela ne ferait aucune différence si nous modifiions le 128 par défaut.

Je pensais que cela pourrait être une preuve suffisante:

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

mais ce n'est pas.

Est-ce que quelqu'un connaît une méthode pour en témoigner avec deux machines, assis sur un réseau Gbit? Le meilleur serait contre MySQL, LVS, apache2 (2.2), memcached.

La définition net.core.somaxconnde valeurs plus élevées n'est nécessaire que sur les serveurs surchargés où le nouveau taux de connexion est si élevé / en rafale que d'avoir 128 (50% de plus dans les BSD: 128 backlog+ 64 half-open) des connexions non encore acceptées est considéré comme normal. Ou lorsque vous devez déléguer la définition de "normal" à une application elle-même.

Certains administrateurs utilisent high net.core.somaxconnpour masquer les problèmes avec leurs services, donc du point de vue de l'utilisateur, cela ressemblera à un pic de latence au lieu d'une connexion interrompue / timeout (contrôlé par net.ipv4.tcp_abort_on_overflowsous Linux).

listen(2)le manuel dit - net.core.somaxconnagit uniquement la 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 n'utilisent que listen(fd, -1)ce qui signifie définir le backlog à la valeur maximale autorisée par le système.

La cause réelle est soit un faible taux de traitement (par exemple, un serveur de blocage à thread unique) ou un nombre insuffisant de threads / processus de travail (par exemple, un logiciel de blocage multi-processus / thread comme apache/ tomcat)

PS. Parfois, il est préférable d'échouer rapidement et de laisser l'équilibreur de charge faire son travail (réessayer) plutôt que de faire patienter l'utilisateur - à cette fin, nous définissons net.core.somaxconnn'importe quelle valeur et limitons le retard d'application par exemple à 10et défini net.ipv4.tcp_abort_on_overflowà 1.

PPS. Les anciennes versions du noyau Linux ont un bug désagréable de tronquer la somaxconvaleur à ses 16 bits inférieurs (c'est-à-dire de convertir la valeur en uint16_t), donc augmenter cette valeur à plus que ce qui 65535peut même être dangereux. Pour plus d'informations, voir: http://patchwork.ozlabs.org/patch/255460/

Si vous souhaitez entrer dans plus de détails sur tous les composants internes du backlog sous Linux, n'hésitez pas à lire: Comment fonctionne le backlog TCP sous Linux .