Nous avons eu un petit problème de basculement avec l'une de nos machines virtuelles HAProxy aujourd'hui. Lorsque nous avons creusé, nous avons trouvé ceci:
26 janvier 07:41:45 noyau haproxy2: [226818.070059] __ratelimit: 10 rappels supprimés 26 janvier 07:41:45 noyau haproxy2: [226818.070064] Mémoire de socket insuffisante 26 janvier 07:41:47 noyau haproxy2: [226819.560048] Mémoire de socket insuffisante 26 janvier 07:41:49 noyau haproxy2: [226822.030044] Mémoire de socket insuffisante
Ce qui, selon ce lien , a apparemment à voir avec des paramètres par défaut bas pour net.ipv4.tcp_mem
. Nous les avons donc augmentés de 4x par rapport à leurs valeurs par défaut (il s'agit d'Ubuntu Server, je ne sais pas si la saveur Linux est importante):
les valeurs actuelles sont: 45984 61312 91968 les nouvelles valeurs sont: 183936 245248 367872
Après cela, nous avons commencé à voir un message d'erreur bizarre:
26 janvier 08:18:49 noyau haproxy1: [2291.579726] Route de hachage trop longue! 26 janvier 08:18:49 noyau haproxy1: [2291.579732] Ajustez votre secret_interval!
Chut .. c'est un secret !!
Cela a apparemment à voir avec la valeur par /proc/sys/net/ipv4/route/secret_interval
défaut de 600 et contrôle le vidage périodique du cache de route
Le
secret_interval
indique au noyau à quelle fréquence supprimer TOUTES les entrées de hachage de route, quelle que soit leur ancienneté. Dans notre environnement, c'est généralement mauvais. Le CPU sera occupé à reconstruire des milliers d'entrées par seconde chaque fois que le cache est effacé. Cependant, nous l'avons configuré pour s'exécuter une fois par jour pour éviter les fuites de mémoire (bien que nous n'en ayons jamais eu).
Bien que nous soyons heureux de réduire cela, il semble étrange de recommander de supprimer l'intégralité du cache de routage à intervalles réguliers , plutôt que de simplement retirer plus rapidement les anciennes valeurs du cache de routage.
Après quelques recherches, nous avons trouvé /proc/sys/net/ipv4/route/gc_elasticity
ce qui semble être une meilleure option pour contrôler la taille de la table de routage:
gc_elasticity
peut être décrit comme la profondeur moyenne du compartiment que le noyau acceptera avant de commencer à expirer les entrées de hachage de route. Cela aidera à maintenir la limite supérieure des itinéraires actifs.
Nous avons ajusté l'élasticité de 8 à 4, dans l'espoir que le cache de route se taille plus agressivement. Cela secret_interval
ne nous semble pas correct. Mais il y a un tas de paramètres et on ne sait pas vraiment quelle est la bonne façon d'aller ici.
- / proc / sys / net / ipv4 / route / gc_elasticity (8)
- / proc / sys / net / ipv4 / route / gc_interval (60)
- / proc / sys / net / ipv4 / route / gc_min_interval (0)
- / proc / sys / net / ipv4 / route / gc_timeout (300)
- / proc / sys / net / ipv4 / route / secret_interval (600)
- / proc / sys / net / ipv4 / route / gc_thresh (?)
- rhash_entries (paramètre du noyau, valeur par défaut inconnue?)
Nous ne voulons pas faire le routage Linux pire , donc nous sommes un peu peur de jouer avec certains de ces paramètres.
Quelqu'un peut-il indiquer les paramètres de routage les mieux adaptés, pour une instance HAProxy à fort trafic?