Bonjour,
je rencontre un problème d'établissement de connexions TCP sur un serveur par forte charge, qui se concrétise par des timeouts de connexion. Ce serveur établit de nombreuses connexions : - serveur web NGiNX - fichiers statiques sur NFSv4 (4 connexions TCP) - reverse-proxy sur une 20ène de serveurs web Apache2/PHP, via l'IP publique - reverse-proxy sur un cluster XMPP
Evidemment il y a quelques axes d'améliorations simple : passer par le réseau privé pour limiter les connexions sur l'interface réseau publique, ... mais ce n'est pas le but de ce mail.
Sous forte charge, parfois une simple connexion TCP a des difficultés pour s'établir. Pour tester, j'écarte des soucis potentiels avec NGiNX et lance un serveur netcat sur le port 8080 : nc -l -k 8080
et depuis un poste client sous Linux : while true; do date -R | tee -a /dev/stderr | nc -w 2 perceval.local 8080 || echo ERR; sleep 0.2; done
Lorsque le problème survient, des "ERR" s'affichent.
A ce moment, j'ai tenté plusieurs choses pour tenter de trouver la source de ces problèmes de connexions, et aucun ne s'est avéré "payant" : - désactiver le firewall - supprimer et décharger conntrack - changer l'algorythme de congestion TCP de cubic à autre chose - mesurer le nombre de connexions TCP établit ou en FIN_WAIT : à 10k total le soucis peut très bien se produire ou pas - modifier plusieurs paramètre de config TCP / Kernel : net.ipv4.tcp_sack = 1 net.ipv4.tcp_fack = 1 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_syncookies = 0 net.ipv4.tcp_low_latency = 0 net.core.netdev_max_backlog = 4000 net.ipv4.ip_local_port_range = 1024 65000 net.ipv4.tcp_max_syn_backlog = 163840 net.ipv4.tcp_synack_retries = 1 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_no_metrics_save = 1 net.ipv4.tcp_max_tw_buckets = 400000 net.core.somaxconn = 8192 fs.file-max = 1310720 net.ipv4.tcp_tw_recycle=1 net.ipv4.tcp_tw_reuse=1
En vain. Sauf un paramètre qui débloque tout quand il est désactivé : net.ipv4.tcp_timestamps=0
C'est très net, si je désactive les timestamps TCP coté serveur (ou coté client forcément), je n'ai plus aucun problème d'établissement de connexions TCP.
A ce moment commence les recherches sur Google, et tout ce que je trouve est ambigu : il vaut mieux activer les timestamps TCP pour des raisons de performances, mais il faut mieux les désactiver pour des problèmes de sécurité. Activé, l'attaquant peut récupérer l'uptime du serveur... Franchement osef nan ? Ce qui me gène plus, c'est qu'il est conseillé d'activer ce paramètre en cas de soucis de congestion TCP...
Peut-être qu'avec la quantité de trafic, le kernel n'est pas capable de fournir assez de timestamps ? Peut-être que la fréquence du timer Linux a une incidence ? Le kernel utilisé est le 3.5.5 avec les patchs Google d'activé (RPS, RFS) et cette config de timer : CONFIG_NO_HZ=y CONFIG_HZ_250=y CONFIG_HZ=250
J'essaye avec 1000 HZ : aucune incidence.
La désactivation de ce paramètre net.ipv4.tcp_timestamps ne doit pas agir que sur les timestamps, peut-être que les algos de congestion TCP, ou certains modules, ou une partie de la stack TCP, utilisent les timestamps TCP, et peut-être que c'est un de ces modules qui pose problème ?
Avez vous déjà expérimenté ce type de soucis ? Je suis dispo pour faire des tests si vous avez des idées !!
❦ 23 juillet 2013 09:29 CEST, Greg greg-frsag@duchatelet.net :
net.ipv4.tcp_tw_recycle=1 net.ipv4.tcp_tw_reuse=1
tcp_tw_recycle est très dangereux et peut causer divers problèmes difficiles à diagnostiquer, notamment une impossibilité pour certains clients d'établir la connexion.
A ce moment commence les recherches sur Google, et tout ce que je trouve est ambigu : il vaut mieux activer les timestamps TCP pour des raisons de performances, mais il faut mieux les désactiver pour des problèmes de sécurité. Activé, l'attaquant peut récupérer l'uptime du serveur... Franchement osef nan ? Ce qui me gène plus, c'est qu'il est conseillé d'activer ce paramètre en cas de soucis de congestion TCP...
Les timestamps te permettent d'obtenir une meilleure estimation du RTT qui est ensuite utilisé à pas mal d'endroits, notamment pour les retransmissions et la gestion des SACK.
A mon avis, tu ne devrais pas changer autant de choses dans les sysctl.
net.ipv4.tcp_sack = 1 net.ipv4.tcp_fack = 1 net.ipv4.tcp_window_scaling = 1
Ce sont les valeurs par défaut.
net.ipv4.tcp_syncookies = 0
Si tu fais ça pour supprimer le message indiquant l'activation des syncookies, tu empires juste le problème. Si tu as régulièrement un message à propos des syncookies, cela signifie que ton application ne suit pas derrière. Tu peux augmenter la listening queue au niveau de l'application de ou de l'OS pour fixer ça si besoin, mais fondamentalement, ça veut dire que y'a un soucis de charge sur l'appli. Les syncookies permettent de mitiger l'effet. Sans les syncookies, la connexion est simplement refusée.
net.core.netdev_max_backlog = 4000 net.ipv4.tcp_max_syn_backlog = 163840
Sans les syncookies, des valeurs aussi hautes, si elles sont ensuite suivies par les applications, vont juste remplir ta table de session avec des SYN_RECV.
net.ipv4.ip_local_port_range = 1024 65000
OK pour ça.
net.ipv4.tcp_synack_retries = 1
C'est plutôt agressif. Du point de vue de l'user, surtout s'il est sur un réseau mobile, cela va se traduire par des pages inaccessibles ou des images cassées.
net.ipv4.tcp_fin_timeout = 10
Généralement, on a pas beaucoup de FIN qui traînent.
net.ipv4.tcp_no_metrics_save = 1
Je le découvre. Vu le nom, je pense que cela signifie que Linux ne va pas stocker les caractéristiques d'un peer et recommencer de 0. Cela me semble une mauvaise idée.
net.ipv4.tcp_max_tw_buckets = 400000 net.ipv4.tcp_tw_recycle=1 net.ipv4.tcp_tw_reuse=1
C'est les trucs typiques que l'on met quand on s'affole du nombre de TIMEWAIT. La première valeur est calculée dynamiquement par le noyau. En mettre une fixe, c'est prendre le risque de ne plus être adapté dans 2 ans. Si tu n'as pas d'erreur concernant un nombre excessif de timewait, ce n'est pas la peine de changer cette valeur.
Pour résoudre le problème des TIMEWAIT, il ne faut pas tenter de les réduire. Ils ne posent problème que quand tu as un nombre limité de quadruplets. Genre un reverse proxy qui cause avec un backend sur le port 80. Ça fait environ 65k quadruplets possibles. Avec le TIMEWAIT qui dure une minute, ça te limite à 1000 connexions/s. Pour corriger ça, tu peux utiliser différents ports ou différentes IP.
net.core.somaxconn = 8192
À ne changer que si on a les messages sur les syncookies de manière régulière. Nécessite aussi une modif côté applicatif.
fs.file-max = 1310720
Oui.
jolie réponse et merci d'avoir partagé avec le reste de la liste ! :)
/s
frsag-bounces@frsag.org wrote on 23/07/2013 10:05:39:
From: Vincent Bernat bernat@luffy.cx To: Greg greg-frsag@duchatelet.net Cc: French SysAdmin Group frsag@frsag.org Date: 23/07/2013 10:05 Subject: Re: [FRsAG] Incidence des TCP Timestamps sur les connexions Sent by: frsag-bounces@frsag.org
❦ 23 juillet 2013 09:29 CEST, Greg greg-frsag@duchatelet.net :
net.ipv4.tcp_tw_recycle=1 net.ipv4.tcp_tw_reuse=1
tcp_tw_recycle est très dangereux et peut causer divers problèmes difficiles à diagnostiquer, notamment une impossibilité pour certains clients d'établir la connexion.
A ce moment commence les recherches sur Google, et tout ce que je
trouve
est ambigu : il vaut mieux activer les timestamps TCP pour des raisons de performances, mais il faut mieux les désactiver pour des problèmes de sécurité. Activé, l'attaquant peut récupérer l'uptime du serveur... Franchement
osef
nan ? Ce qui me gène plus, c'est qu'il est conseillé d'activer ce paramètre
en
cas de soucis de congestion TCP...
Les timestamps te permettent d'obtenir une meilleure estimation du RTT qui est ensuite utilisé à pas mal d'endroits, notamment pour les retransmissions et la gestion des SACK.
A mon avis, tu ne devrais pas changer autant de choses dans les sysctl.
net.ipv4.tcp_sack = 1 net.ipv4.tcp_fack = 1 net.ipv4.tcp_window_scaling = 1
Ce sont les valeurs par défaut.
net.ipv4.tcp_syncookies = 0
Si tu fais ça pour supprimer le message indiquant l'activation des syncookies, tu empires juste le problème. Si tu as régulièrement un message à propos des syncookies, cela signifie que ton application ne suit pas derrière. Tu peux augmenter la listening queue au niveau de l'application de ou de l'OS pour fixer ça si besoin, mais fondamentalement, ça veut dire que y'a un soucis de charge sur l'appli. Les syncookies permettent de mitiger l'effet. Sans les syncookies, la connexion est simplement refusée.
net.core.netdev_max_backlog = 4000 net.ipv4.tcp_max_syn_backlog = 163840
Sans les syncookies, des valeurs aussi hautes, si elles sont ensuite suivies par les applications, vont juste remplir ta table de session avec des SYN_RECV.
net.ipv4.ip_local_port_range = 1024 65000
OK pour ça.
net.ipv4.tcp_synack_retries = 1
C'est plutôt agressif. Du point de vue de l'user, surtout s'il est sur un réseau mobile, cela va se traduire par des pages inaccessibles ou des images cassées.
net.ipv4.tcp_fin_timeout = 10
Généralement, on a pas beaucoup de FIN qui traînent.
net.ipv4.tcp_no_metrics_save = 1
Je le découvre. Vu le nom, je pense que cela signifie que Linux ne va pas stocker les caractéristiques d'un peer et recommencer de 0. Cela me semble une mauvaise idée.
net.ipv4.tcp_max_tw_buckets = 400000 net.ipv4.tcp_tw_recycle=1 net.ipv4.tcp_tw_reuse=1
C'est les trucs typiques que l'on met quand on s'affole du nombre de TIMEWAIT. La première valeur est calculée dynamiquement par le noyau. En mettre une fixe, c'est prendre le risque de ne plus être adapté dans 2 ans. Si tu n'as pas d'erreur concernant un nombre excessif de timewait, ce n'est pas la peine de changer cette valeur.
Pour résoudre le problème des TIMEWAIT, il ne faut pas tenter de les réduire. Ils ne posent problème que quand tu as un nombre limité de quadruplets. Genre un reverse proxy qui cause avec un backend sur le port 80. Ça fait environ 65k quadruplets possibles. Avec le TIMEWAIT qui dure une minute, ça te limite à 1000 connexions/s. Pour corriger ça, tu peux utiliser différents ports ou différentes IP.
net.core.somaxconn = 8192
À ne changer que si on a les messages sur les syncookies de manière régulière. Nécessite aussi une modif côté applicatif.
fs.file-max = 1310720
Oui.
Don't compare floating point numbers just for equality. - The Elements of Programming Style (Kernighan & Plauger) _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-
Greg -
Stephane.DIENY＠somfy.com -
Vincent Bernat