[FRsAG] VMWARE / Debian 10 / Problème interruptions sur cartes réseau

Fabien H frnog.fabien at gmail.com
Mer 15 Sep 17:29:52 CEST 2021


Bonjour,

je vous tiens au courant des différents tests que j'ai fait :

Config d'origine : Debian 10, Carte réseau E1000, 16 vCPU, pas d'IRQBalance
: en pleine charge, load 15min à 5 en moyenne avec des pics à 8 à 5min.

- Carte réseau E1000 avec Pining des 8 premiers CPU sur l'hôte : en pleine
charge, load 15min à 4,5 avec des pics à 8 à 5min. (peu de changement)
- Passage du kernel 4.19 à 5.10 => peu de changement remarqué mais je l'ai
laissé
- Passage de E1000 à VMXNET3 sans pining CPU : en pleine charge, load 15min
à 2,5-3, pas de gros pics (on bénéficie du multiqueue 8 queues pour chaque
carte VMXNET3 !)
- VMXNET3 sans pining CPU avec CPU affinity de chacune des IRQ des 8 queues
des 2 cartes réseaux sur chacun des 16 CPU : en pleine charge, load 15min à
2-2,5, pas de gros pics

Configuration finale :

- Debian 10 avec noyau 5.10
- 2 cartes VMXNET3
- 16 vCPU
- Pining de 8 CPU physiques sur 8 CPU virtuels (les 8 autres virtuels ne
bénéficient pas de pining car ça commence à faire beaucoup de CPU reservés
sur l'hôte..!)
- CPU affinity des IRQ des 8 queues de chaque carte VMXNET3 ens sur les 8
CPU virtuels avec Pining (donc chaque CPU virtuel (ou physique) accueille 2
IRQ des queues rxtx VMXNET3)

Résultat : en pleine charge, load 15min à 1,5 environ, pas de gros pics

Je suis assez content du résultat!

La config idéale je pense serai d'avoir 16 CPU physiques en pining =>  16
CPU virtuels correspondants et de faire l'affinité des IRQ des 8 queues x 2
cartes VMXNET3 sur les 16 CPU. Si jamais dans quelques mois ou années, la
charge ne tient pas, je ferai ça :

(A noter que j'ai été obligé de faire un script de CPU affinity au boot
pour que les IRQ ens*-rxtx ne se recouvrent sur un même CPU pas car en
fait, il y'a les IRQ ens*-event qui décalent la répartition)


# cat /proc/interrupts | grep ens
65:   36603230          0          0          1          0
0          0          0          0          0          0
0          0          0          0          0   PCI-MSI 9961472-edge
ens224-rxtx-0
  66:          0   38123550          0          0          1
0          0          0          0          0          0
0          0          0          0          0   PCI-MSI 9961473-edge
ens224-rxtx-1
  67:          0          0   10871871          0          0
1          0          0          0          0          0
0          0          0          0          0   PCI-MSI 9961474-edge
ens224-rxtx-2
  68:          0          0          0   10148151          0
0          2          0          0          0          0
0          0          0          0          0   PCI-MSI 9961475-edge
ens224-rxtx-3
  69:          0          0          0          0   24397483
0          0          1          0          0          0
0          0          0          0          0   PCI-MSI 9961476-edge
ens224-rxtx-4
  70:          0          0          0          0          0
23471080          0          0          1          0          0
0          0          0          0          0   PCI-MSI 9961477-edge
ens224-rxtx-5
  71:          0          0          0          0          0          0
25145320          0          0          1          0          0
0          0          0          0   PCI-MSI 9961478-edge      ens224-rxtx-6
  72:          0          0          0          0          0
0          0   22992945          0          0          1
0          0          0          0          0   PCI-MSI 9961479-edge
ens224-rxtx-7
  73:          0          0          0          0          0
0          0          0          0          0          0
0          0          0          0          0   PCI-MSI 9961480-edge
ens224-event-8
  74:          0          0          0          0          0
0          0          0   10838656          0          0
0          2          0          0          0   PCI-MSI 14155776-edge
ens256-rxtx-0
  75:          0          0          0          0          0
0          0          0          0   10384015          0
0          0          1          0          0   PCI-MSI 14155777-edge
ens256-rxtx-1
  76:          0          0          0          0          0
0          0          0          0          0   16895371
0          0          0          1          0   PCI-MSI 14155778-edge
ens256-rxtx-2
  77:          0          0          0          0          0
0          0          0          0          0          0
10538689          0          0          0          2   PCI-MSI
14155779-edge      ens256-rxtx-3
  78:          2          0          0          0          0
0          0          0          0          0          0          0
10074542          0          0          0   PCI-MSI 14155780-edge
ens256-rxtx-4
  79:          0          1          0          0          0
0          0          0          0          0          0
0          0   40401515          0          0   PCI-MSI 14155781-edge
ens256-rxtx-5
  80:          0          0          1          0          0
0          0          0          0          0          0
0          0          0   27866098          0   PCI-MSI 14155782-edge
ens256-rxtx-6
  81:          0          0          0          1          0
0          0          0          0          0          0
0          0          0          0   42105767   PCI-MSI 14155783-edge
ens256-rxtx-7
  82:          0          0          0          0          0
0          0          0          0          0          0
0          0          0          0          0   PCI-MSI 14155784-edge
ens256-event-8



Il fallait donc bien distribuer les soft-IRQ sur tous les CPU comme vous me
l'aviez dit ! (je confondais IRQBalance et CPU affinity des IRQ. Je n'avais
pas compris non plus  que VMXNET3 est multiqueue depuis très longtemps sur
le guest alors que E1000 est mono-queue donc 1 CPU pour l'IRQ E1000...). Je
ne sais pas si le noyau 5.10 apporte quelque chose..

Merci à tous,
Fabien



Le ven. 10 sept. 2021 à 20:30, Fabien H <frnog.fabien at gmail.com> a écrit :

> Bonsoir Gurvan,
> Merci
> oui la réponse de Rémy m'a mis sur la piste, je vais désactiver tout ce
> que je peux désactiver et je testerai sur un samedi ou dimanche.. J'essaye
> de tenir au courant la liste dès qu'il y'a du nouveau..
>
>
> Le ven. 10 sept. 2021 à 19:38, Inulogic - Gurvan Rottier-Ripoche <
> inulogic at gmail.com> a écrit :
>
>> Hello,
>>
>> J'avais bench debian sur du web dans les 600/700mbits en désactivant
>> toutes les mitig/microcode (et en m'arrêtant au patch vmware juste
>> avant l'intégration), il y avait une sacrée différence avec un truc
>> tout à jour.
>> Il est fort possible que le load bouge pas mal à cause des différentes
>> mitigations, à tester avec spectre-meltdown-checker.
>> Il faut désactiver via le grub et aussi vérifier la version de l'esxi.
>> GRUB_CMDLINE_LINUX_DEFAULT="quiet noibrs noibpb nopti nospectre_v2
>> nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier
>> mds=off tsx=on tsx_async_abort=off mitigations=off"
>> (Il y a des doublons je crois mais je me souviens jamais lesquels).
>>
>>
>> Gurvan.
>>
>> Le ven. 10 sept. 2021 à 16:44, Fabien H <frnog.fabien at gmail.com> a écrit
>> :
>> >
>> > Bonjour Remi,
>> > Intéressant mitigations=off je vais essayer
>> > Merci
>> >
>> > Le ven. 10 sept. 2021 à 16:36, Rémy Duchet <remy at duchet.eu> a écrit :
>> >>
>> >> Bonjour,
>> >>
>> >>
>> >>
>> >> Pour chaque nouvel ajout (hardware / Guest / etc ) on fait des tests
>> de perfs. Ça aide à voir les perfs des OS et parfois les perfs hard réel.
>> >>
>> >> J’ai aussi expérimenté  mitigations=off sur  /boot/grub/grub.cfg sur
>> une config de routage (VyOS) qui ramait en perf UDP..
>> >>
>> >>
>> >>
>> >> Rémy
>> >>
>> >>
>> >>
>> >> From: FRsAG <frsag-bounces at frsag.org> On Behalf Of Fabien H
>> >> Sent: Friday, 10 September 2021 16:15
>> >> To: frsag <frsag at frsag.org>
>> >> Subject: Re: [FRsAG] VMWARE / Debian 10 / Problème interruptions sur
>> cartes réseau
>> >>
>> >>
>> >>
>> >> Bonjour Frederic,
>> >>
>> >>
>> >>
>> >> les nouvelles VM sont sur le même vSwitch que les anciennes sur le
>> même cluster d'hôtes qui sont sensiblement identiques.. Tests croisés faits
>> déjà..
>> >>
>> >>
>> >>
>> >> Le ven. 10 sept. 2021 à 16:05, Frederic Hermann <fhe-frsag at neptune.fr>
>> a écrit :
>> >>
>> >> Citation maison :
>> >>
>> >>
>> >>
>> >> "90% des problèmes réseaux sont des problèmes de cablage. "
>> >>
>> >> " ... le reste, c'est des problèmes de MTU"
>> >>
>> >>
>> >>
>> >> Il faudrait vérifier s'il n'y a pas une rupture de MTU quelque part.
>> >>
>> >> La charge CPU pourrait être lié a de la fragmentation : est-ce qu'un
>> ping -M do 1472 <ip de la VM> passe sans problème ?
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ________________________________
>> >>
>> >> De: "Fabien H" <frnog.fabien at gmail.com>
>> >> À: "frsag" <frsag at frsag.org>
>> >> Envoyé: Vendredi 10 Septembre 2021 14:01:35
>> >> Objet: Re: [FRsAG]         VMWARE / Debian 10 / Problème interruptions
>> sur cartes réseau
>> >>
>> >> Bonjour Nicolas,
>> >>
>> >>
>> >>
>> >> c'est de la Voip.. Non justement ce qui diffère entre les 2 : l'OS
>> debian est différent, et l'applicatif est différent également (sauf de 2
>> versions). Remettre le noyau de la debian 8 sur la debian 10 ? intéressant
>> :-)
>> >>
>> >>
>> >>
>> >> On est loin des 1 Gbps ! Par contre on a pas mal de petits paquets car
>> c'est de la VOIP
>> >>
>> >>
>> >>
>> >>
>> >
>> > _______________________________________________
>> > Liste de diffusion du FRsAG
>> > http://www.frsag.org/
>> _______________________________________________
>> Liste de diffusion du FRsAG
>> http://www.frsag.org/
>>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://www.frsag.org/pipermail/frsag/attachments/20210915/be03b762/attachment-0001.htm>


Plus d'informations sur la liste de diffusion FRsAG