Y a-t-il encore une utilisation pour l'irqbalance sur le matériel moderne?
Cette question a déjà été posée, mais je pense que le monde a suffisamment changé pour qu'elle puisse être posée à nouveau.
Irqbalance a-t-il une utilité sur les systèmes actuels où nous avons des processeurs compatibles NUMA avec partage de mémoire entre leurs cœurs?
Fonctionnement irqbalance --oneshot --debug montre qu'un invité virtuel dans un environnement VMware ESXi moderne partage les nœuds NUMA entre les cœurs.
# irqbalance --oneshot --debug 3
Package 0: numa_node is 0 cpu mask is 0000000f (load 0)
Cache domain 0: numa_node is 0 cpu mask is 0000000f (load 0)
CPU number 0 numa_node is 0 (load 0)
CPU number 1 numa_node is 0 (load 0)
CPU number 2 numa_node is 0 (load 0)
CPU number 3 numa_node is 0 (load 0)
irqbalance détectera dans ce cas qu'il est exécuté sur un système NUMA et quittera. Cela gâche notre surveillance des processus.
Devrions-nous chercher à exécuter numad au lieu d'irqbalance sur de tels systèmes?
Ceci est surtout intéressant pour les serveurs virtualisés VMware.
Voici une réponse d'un technicien de RedHat. Bien que je pense que la plupart du matériel d'entreprise est compatible NUMA. Et pour autant que je sache, VMware essaiera également d'adapter vos machines virtuelles sur le même nœud NUMA tant que sa configuration CPU est adaptée.
Des expériences (en particulier concernant VMware) seraient grandement appréciées.
Cela est vrai "à cause" des serveurs modernes. Gardez à l'esprit que Multi-CPU/Muli-Core n'est pas la même chose que NUMA. Il existe de nombreux systèmes multi-CPU/Core qui n'ont pas NUMA.
Avant de lire mon explication ci-dessous, veuillez lire le document IRQ Affinity ci-dessus, ainsi que les guides suivants:
Guide de réglage des performances RHEL 6
Réglage des performances à faible latence pour RHEL 6
Vous avez tout lu? Génial, tu n'as plus besoin de m'entendre! ;-) Mais juste au cas où vous seriez impatient, voici pourquoi vous les voulez ...
IRQbalance empêche toutes les requêtes IRQ de sauvegarder sur un seul processeur. J'ai vu de nombreux systèmes avec plus de 4 cœurs de processeur fonctionner lentement car tous les processus sur divers processeurs attendent sur le processeur 0 pour traiter les demandes d'IRQ de réseau ou de stockage. Le CPU 0 semble très, très occupé, tous les autres CPU ne sont pas occupés, mais les applications sont très lentes. Les applications sont lentes car elles attendent leurs IO requêtes du CPU 0.
IRQbalance essaie d'équilibrer cela de manière intelligente sur tous les processeurs et, lorsque cela est possible, place le traitement IRQ aussi près que possible du processus. Il peut s'agir du même cœur, d'un cœur sur le même dé partageant le même cache ou d'un cœur dans la même zone NUMA.
Vous devez utiliser irqbalance sauf:
Vous épinglez manuellement vos applications/IRQ à des cœurs spécifiques pour une très bonne raison (faible latence, exigences en temps réel, etc.)
Invités virtuels. Cela n'a pas vraiment de sens, car à moins que vous n'épingliez l'invité à des CPU et IRQ spécifiques et à du matériel de stockage/réseau dédié, vous ne verrez probablement pas les avantages que vous obtiendriez sur le métal nu. Mais votre hôte KVM/RHEV DEVRAIT utiliser irqbalance et numad et réglé .
D'autres outils de réglage très importants sont les profils réglés et numad. Lisez à leur sujet! Utilise les!
Numad est similaire à irqbalance en ce sens qu'il essaie de s'assurer qu'un processus et sa mémoire sont dans la même zone numa. Avec de nombreux cœurs, nous constatons une réduction significative des latences, ce qui se traduit par des performances fiables beaucoup plus fluides sous les charges.
Si vous êtes qualifié, diligent et surveillez régulièrement ou avez une charge de travail très prévisible, vous pouvez obtenir de meilleures performances en épinglant manuellement les processus/IRQ aux CPU. Même dans ces situations, irqbalance et numad sont très proches de la correspondance. Mais si vous n'êtes pas certain ou que votre charge de travail est imprévisible, vous devez utiliser irqbalance et numad.