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.fab...@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 < > inulo...@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.fab...@gmail.com> a écrit >> : >> > >> > Bonjour Remi, >> > Intéressant mitigations=off je vais essayer >> > Merci >> > >> > Le ven. 10 sept. 2021 à 16:36, Rémy Duchet <r...@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-boun...@frsag.org> On Behalf Of Fabien H >> >> Sent: Friday, 10 September 2021 16:15 >> >> To: frsag <frsag@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-fr...@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.fab...@gmail.com> >> >> À: "frsag" <frsag@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/ >> >
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
