J'exécute un ensemble de tests de charge pour déterminer les performances de la configuration suivante:
Node.js test suite (client) --> StatsD (server) --> Graphite (server)
En bref, la suite de tests node.js envoie une quantité définie de métriques toutes les x secondes à une instance StatsD située sur un autre serveur. StatsD vide ensuite à son tour les métriques chaque seconde dans une instance Graphite située sur le même serveur. Je regarde ensuite combien de métriques ont été réellement envoyées par la suite de tests et combien ont été reçues par Graphite pour déterminer la perte de paquets entre la suite de tests et Graphite.
Cependant, j'ai remarqué que j'obtenais parfois des taux de chute de paquets très importants (notez qu'il est envoyé avec le protocole UDP), allant de 20 à 50%. C'est donc à ce moment-là que j'ai commencé à chercher où ces paquets étaient abandonnés, car cela pourrait être un problème de performances avec StatsD. J'ai donc commencé à enregistrer les métriques dans chaque partie du système pour localiser où cette baisse s'est produite. Et c'est là que les choses deviennent étranges.
J'utilise tcpdump pour créer un fichier de capture que j'inspecte une fois le test terminé. Mais chaque fois que j'exécute les tests avec tcpdump en cours d'exécution, la perte de paquets est presque inexistante! Il semble que tcpdump augmente en quelque sorte les performances de mes tests et je ne peux pas comprendre pourquoi et comment cela se fait. J'exécute la commande suivante pour enregistrer les messages tcpdump sur le serveur et le client:
tcpdump -i any -n port 8125 -w test.cap
Dans un cas de test particulier, j'envoie 40000 métriques / s. Le test lors de l'exécution de tcpdump a une perte de paquets d'environ 4% tandis que celui sans a une perte de paquets d'environ 20%
Les deux systèmes fonctionnent en tant que VM Xen avec la configuration suivante:
- Intel Xeon E5-2630 v2 à 2,60 GHz
- 2 Go de RAM
- Ubuntu 14.04 x86_64
Choses que j'ai déjà vérifiées pour les causes potentielles:
- Augmentation de la taille de réception / d'envoi du tampon UDP.
- Charge CPU affectant le test. (charge maximale de 40 à 50%, côté client et côté serveur)
- Exécuter tcpdump sur des interfaces spécifiques au lieu de 'any'.
- Exécuter tcpdump avec '-p' pour désactiver le mode promiscuous.
- Exécution de tcpdump uniquement sur le serveur. Cela a entraîné une perte de paquets de 20% et ne semble pas avoir d'impact sur les tests.
- Exécution de tcpdump uniquement sur le client. Cela a entraîné une augmentation des performances.
- Augmentation de netdev_max_backlog et netdev_budget à 2 ^ 32-1. Cela n'a fait aucune différence.
- J'ai essayé tous les paramètres possibles du mode promiscuous sur chaque nic (serveur allumé et client éteint, serveur éteint et client allumé, les deux allumés, les deux éteints). Cela n'a fait aucune différence.
ifconfig eth0 promisc
active et ifconfig eth0 -promisc
désactive le mode promiscuous sur eth0. Si cela fait la différence, essayez de comparer les 4 combinaisons possibles de promisc on / off sur les deux machines. Cela pourrait aider à identifier la source des problèmes.
-p
option pour ignorer cela pour voir si cela fait une différence.