Pourquoi les performances de TCP accept () sont-elles si mauvaises sous Xen?
La vitesse à laquelle mon serveur peut accepter () de nouvelles connexions TCP TCP entrantes est vraiment mauvaise sous Xen. Le même test sur du matériel nu montre des accélérations de 3 à 5 fois.
- Pourquoi est-ce si mauvais sous Xen?
- Pouvez-vous modifier Xen pour améliorer les performances des nouvelles connexions TCP?
- Existe-t-il d'autres plateformes de virtualisation mieux adaptées à ce type de cas d'utilisation?
Contexte
Dernièrement, j'ai recherché certains goulots d'étranglement des performances d'un serveur développé en interne Java serveur fonctionnant sous Xen. Le serveur parle HTTP et répond simplement TCP connect/request/répondre/déconnecter les appels.
Mais même lors de l'envoi de bateaux de trafic vers le serveur, il ne peut pas accepter plus de ~ 7000 TCP par seconde (sur une instance EC2 à 8 cœurs, c1.xlarge exécutant Xen). , le serveur présente également un comportement étrange où un cœur (pas nécessairement cpu 0) est très chargé> 80%, tandis que les autres cœurs restent presque inactifs. Cela m'amène à penser que le problème est lié au noyau/à la virtualisation sous-jacente.
Lorsque je teste le même scénario sur une plate-forme sans métal non virtualisée, j'obtiens des résultats de test montrant des taux de TCP accept () supérieurs à 35 000/seconde. Ceci sur une machine Core i5 4 core exécutant Ubuntu avec tous les cœurs presque entièrement saturés. Pour moi, ce genre de figure semble à peu près juste.
Sur l'instance Xen, j'ai essayé d'activer/de modifier presque tous les paramètres du sysctl.conf. Y compris l'activation Receive Packet Steering et Receive Flow Steering et l'épinglage des threads/processus sur les CPU mais sans gains apparents.
Je sais que des performances dégradées sont à prévoir lors de l'exécution virtualisée. Mais à ce degré? Un serveur bare metal plus lent et plus performant que virt. 8 cœurs par un facteur de 5?
- Est-ce vraiment le comportement attendu de Xen?
- Pouvez-vous modifier Xen pour améliorer les performances des nouvelles connexions TCP?
- Existe-t-il d'autres plateformes de virtualisation mieux adaptées à ce type de cas d'utilisation?
Reproduire ce comportement
En approfondissant cela et en identifiant le problème, j'ai découvert que l'outil de test de performance netperf pouvait simuler le scénario similaire que je vis. En utilisant le test TCP_CRR de netperf, j'ai collecté divers rapports de différents serveurs (virtualisés et non virtuels). Si vous souhaitez contribuer à certaines conclusions ou consulter mes rapports actuels, veuillez consulter https://Gist.github.com/985475
Comment savoir si ce problème n'est pas dû à un logiciel mal écrit?
- Le serveur a été testé sur du matériel en métal nu et il sature presque tous les cœurs disponibles.
- Lors de l'utilisation de connexions keep-alive TCP, le problème disparaît.
Pourquoi est-ce important?
Chez ESN (mon employeur), je suis le chef de projet de Beaconpush , un serveur Comet/Web Socket écrit en Java. Même s'il est très performant et peut saturer presque toute la bande passante qui lui est donnée dans des conditions optimales, il est toujours limité à la vitesse à laquelle de nouvelles connexions TCP peuvent être établies. Autrement dit, si vous avez un gros taux de désabonnement utilisateur où les utilisateurs vont et viennent très souvent, de nombreuses connexions TCP devront être établies/supprimées. Nous essayons d'atténuer cela en maintenant les connexions en vie aussi longtemps que possible. Mais au final, l'acceptation () la performance est ce qui empêche nos cœurs de tourner et nous n'aimons pas cela.
Mise à jour 1
Quelqu'un a posté cette question sur Hacker News , il y a aussi des questions/réponses. Mais je vais essayer de garder cette question à jour avec les informations que je trouve au fur et à mesure.
Matériel/plateformes sur lesquelles j'ai testé ceci:
- EC2 avec les types d'instance c1.xlarge (8 cœurs, 7 Go de RAM) et cc1.4xlarge (2x Intel Xeon X5570, 23 Go de RAM). Les AMI utilisées étaient respectivement AMI-08f40561 et AMI-1cad5275. Quelqu'un a également souligné que les "groupes de sécurité" (c'est-à-dire le pare-feu EC2) pourraient également affecter. Mais pour ce scénario de test, j'ai essayé uniquement sur localhost d'éliminer des facteurs externes tels que celui-ci. Une autre rumeur que j'ai entendue est que les instances EC2 ne peuvent pas pousser plus de 100k PPS.
- Deux serveurs virtualisés privés exécutant Xen. L'un n'avait aucune charge avant le test, mais cela ne faisait aucune différence.
- Serveur privé dédié Xen chez Rackspace. À peu près les mêmes résultats là-bas.
Je suis en train de relancer ces tests et de remplir les rapports sur https://Gist.github.com/985475 Si vous souhaitez aider, indiquez vos chiffres. C'est facile!
(Le plan d'action a été déplacé vers une réponse consolidée distincte)
À l'heure actuelle: les performances des petits paquets sont nulles sous Xen
(déplacé de la question elle-même à une réponse distincte à la place)
Selon un utilisateur sur HN (un KVM?), Cela est dû aux performances des petits paquets dans Xen et également KVM. C'est un problème connu de virtualisation et selon lui, ESX de VMWare gère autant Il a également noté que KVM apportent de nouvelles fonctionnalités conçues pour atténuer cela ( article d'origine ).
Cette information est un peu décourageante si elle est correcte. Quoi qu'il en soit, je vais essayer les étapes ci-dessous jusqu'à ce qu'un gourou Xen arrive avec une réponse définitive :)
Iain Kay de la liste de diffusion xen-users a compilé ce graphique: 
Remarquez les barres TCP_CRR, comparez "2.6.18-239.9.1.el5" à "2.6.39 (avec Xen 4.1.0)".
Plan d'action actuel basé sur les réponses/réponses ici et de HN :
Soumettez ce problème à une liste de diffusion spécifique à Xen et au bugzilla de xensource comme suggéré par syneticon-djA le message a été publié dans la liste des utilisateurs xen , en attente de réponse.Créez un scénario de test pathologique simple au niveau de l'application et publiez-le.
Un serveur de test avec des instructions a été créé et publié sur GitHub . Avec cela, vous devriez pouvoir voir un cas d'utilisation plus réel que netperf.Essayez une instance d'invité PV Xen 32 bits, car 64 bits peuvent entraîner plus de surcharge dans Xen. Quelqu'un l'a mentionné sur HN.Cela n'a pas fait de différence.Essayez d'activer net.ipv4.tcp_syncookies dans sysctl.conf comme suggéré par abofh sur HN. Apparemment, cela pourrait améliorer les performances car la prise de contact aurait lieu dans le noyau.Je n'ai pas eu de chance avec ça.Augmentez l'arriéré de 1024 à quelque chose de beaucoup plus élevé, également suggéré par abofh sur HN. Cela pourrait également aider car l'invité pourrait potentiellement accepter () plus de connexions pendant sa tranche d'exécution donnée par dom0 (l'hôte).
Vérifiez que conntrack est désactivé sur toutes les machines car il peut réduire de moitié le taux d'acceptation (suggéré par deubeulyou).Oui, il a été désactivé dans tous les tests.Vérifiez le "débordement de la file d'attente d'écoute et le débordement des compartiments de synchronisation dans netstat -s" (suggéré par mike_esspe sur HN).
Divisez la gestion des interruptions entre plusieurs cœurs (les RPS/RFS que j'ai essayé d'activer plus tôt sont censés le faire, mais cela pourrait valoir la peine d'essayer à nouveau). Suggéré par Adam à HN.
Désactiver TCP segmentation déchargement et dispersion/collecte accélération comme suggéré par Matt Bailey. (Pas possible sur EC2 ou hôtes VPS similaires)
Pour l'anecdote, j'ai constaté que la désactivation de l'accélération matérielle NIC améliore considérablement les performances du réseau sur le contrôleur Xen (également vrai pour LXC):
Accell dispersion-rassemblement:
/usr/sbin/ethtool -K br0 sg off
Déchargement de segmentation TCP:
/usr/sbin/ethtool -K br0 tso off
Où br0 est votre pont ou périphérique réseau sur l'hôte hyperviseur. Vous devrez le configurer pour le désactiver à chaque démarrage. YMMV.
Peut-être pourriez-vous clarifier un peu - avez-vous exécuté les tests sous Xen sur votre propre serveur, ou uniquement sur une instance EC2?
Accepter n'est qu'un autre appel système, et les nouvelles connexions ne sont différentes que dans la mesure où les premiers paquets auront des indicateurs spécifiques - un hyperviseur tel que Xen ne devrait certainement pas voir de différence. D'autres parties de votre configuration pourraient: dans EC2 par exemple, je ne serais pas surpris si les groupes de sécurité y étaient pour quelque chose; conntrack est également rapporté pour réduire de moitié le taux de nouvelles connexions acceptées (PDF) .
Enfin, il semble y avoir des combinaisons CPU/noyau qui provoquent une utilisation/blocage étrange du processeur sur EC2 (et probablement Xen en général), comme publié récemment par Librato .
Assurez-vous d'avoir désactivé iptables et autres hooks dans le code de pontage dans dom0. Évidemment, cela ne s'applique qu'à la configuration de la mise en réseau Xen.
echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 0 > /proc/sys/net/bridge.bridge-nf-call-arptables
Cela dépend de la taille du serveur, mais de plus petits (processeur à 4 cœurs) dédiez un cœur de processeur à Xen dom0 et épinglez-le. Options de démarrage de l'hyperviseur:
dom0_max_vcpus=1 dom0_vcpus_pin dom0_mem=<at least 512M>
Avez-vous essayé de transmettre un périphérique PCI Ethernet physique à domU? Il devrait y avoir une amélioration des performances.