Merci Vincent pour ces explications et recommandations, que j'ai prise en compte.
Néanmoins je me demande toujours pourquoi désactiver les TCP timestamps a un tel impact sur l'établissement des connexions TCP. Damien> je suis en contact aussi avec eux, mais comme tout CDN ils ne peuvent rien faire sur le trafic dynamique ;) Le 23 juillet 2013 12:14, Damien Wetzel <dwet...@nerim.net> a écrit : > Bonjour Greg, > On est en contact via cedexis. > Si l'utilisation du cdn peut soulager vos problemes de perfs n'hesitez pas > à l'utiliser. > Cordialement, > > Greg writes: > > 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 !! > > > > -- > > Greg > > > > > > ---------------------------------------------------------------------- > > _______________________________________________ > > Liste de diffusion du FRsAG > > http://www.frsag.org/ > > -- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Damien WETZEL (ATANAR TECHNOLOGIES) ("`-/")_.-'"``-._ > http://www.atanar.com . . `; -._ )-;-,_`) > (v_,)' _ )`-.\ ``-' > Phone:+33 9 63 05 59 99 _.- _..-_/ / ((.' > - So much to do, so little time - ((,.-' ((,/ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -- Greg
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
