Bonjour Mathieu, firmware des cartes réseau physiques de l'hôte ? Ca pourrait s'envisager mais les hôtes hébergent de nombreuses VM de production donc il y'a un certain risque..
Au passage : j'ai un collègue qui a déployé une VM Windows mais n'a pas de problème de débit avec la VMXNET3 sur du Windows Server 2016 de mémoire.. Après un test de débit ne génère pas forcément le même trafic que l'applicatif que nous avons actuellement (UDP) .. Le ven. 10 sept. 2021 à 13:09, Mathieu <math...@apc-info-services.fr> a écrit : > Bonjour Fabien, > > > > Question bête mais as-tu mis à jour tous les firmwares hardware ? > > J’ai déjà eu des cas plus ou moins similaires qui ont été solutionnés > comme ça. > > > > Cdt, > > Mathieu > > > > *De :* FRsAG <frsag-boun...@frsag.org> *De la part de* Fabien H > *Envoyé :* vendredi 10 septembre 2021 12:22 > *À :* frsag@frsag.org > *Objet :* Re: [FRsAG] VMWARE / Debian 10 / Problème interruptions sur > cartes réseau > > > > D'accord je vais jeter un oeil à cela merci. > > > > irqbalance est bien installé, d'ailleurs je vois remonter les process > ksoftirqd/2 et ksoftirqd/3 lors des fortes charges. > > > > J'ai lu dans la littérature que de toute façon, les interrupt d'une carte > réseau ne seraient pas réparties par irqbalance mais seraient justement > tout le temps traité par le même CPU virtuel pour des raisons de > performance..? > > > > > > Le ven. 10 sept. 2021 à 12:16, Guillaume Vassal <guilla...@vass.al> a > écrit : > > Bonjour, > > J'ai eu ce genre problème sur de la machine physique qui encaisse vraiment > beaucoup de trafic, mais ça doit être valable sur du virtuel. > > Dans un premier temps, pour voir si les IRQ sont mal réparties sur les > différents cœurs sans se prendre la tête tu peux utiliser simplement htop > > F2 > Display Options > [x] Detailed CPU time (.....) > > De visu si tout s'empile sur seulement sur certains cœur c'est qu'il y a > surement un problème de répartition. > > Une piste peut être de vérifier que le service irqbalnce est bien installé > et démarré. Il fait le café tout seul en théorie > > systemctl status irqbalance.service > > Cdt, > -- > Guillaume Vassal > > > 10 septembre 2021 11:55 "Fabien H" <frnog.fab...@gmail.com > <frnog.fab...@gmail.com?to=%22fabien%20h%22%20%3cfrnog.fab...@gmail.com%3E>> > a écrit: > > Bonjour, > > je vais essayer de vous expliquer le problème que nous rencontrons en > essayant d’être concis : > > Nous avons utilisé pendant des années sur 2 VM un applicatif open source > très connu qui fonctionne massivement en multi-threadé, en quasi temps > réel, et en gateway UDP avec mal un trafic UDP qui va en augmentant selon > la charge (les plus perspicaces devineront !) : > > - ESXI : 6.5.0 update 3 > - OS invité : Debian 8 > - Interfaces réseau : E1000 > - 8 vCPU / 16 Go RAM > > Cela a fonctionné très bien même en cas de montée en charge assez > importante. Le load average depasse rarement 0,8 et très stable dans le > temps. Pourtant nous étions bien conscients que les conditions n’étaient > pas optimales sur la type de carte E1000 utilisées. > > Récemment, nous avons déployé 2 nouvelles VM avec le même applicatif mais > en version plus récente et sur un OS plus récent : > - ESXI 6.5.0 update 3 > - OS invité : Debian 10 > - Interface réseau : VMXNET3 (driver integré au noyau 4.19.0-16) > - 8 vCPU / 16 Go RAM > - VMWARE Tools installé > > > Nous avons constaté assez rapidement des problèmes de montée en charge, > avec une charge moderée, le load average est quasi à 0,00. Lors d’une > montée en charge en journée, le load est plutôt en moyenne sur 2 ou 3, et > lors de certains pics de charge part à 4 ou 6, puis retombe à 2-3. Lorsque > la charge retombe. > Je constate que le load average s’envole surtout quand le si est non nul > sur les 2 CPU qui gèrent les interruptions des 2 cartes réseau IN et OUT : > > %Cpu2 : 1.5 us, 1.1 sy, 0.0 ni, 96.6 id, 0.0 wa, 0.0 hi, 0.8 si, 0.0 st > %Cpu3 : 1.1 us, 1.1 sy, 0.0 ni, 97.4 id, 0.0 wa, 0.0 hi, 0.4 si, 0.0 st > > 16: 0 0 529091347 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 16-fasteoi ens34, > vmwgfx > 17: 0 0 0 453037316 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 17-fasteoi ens35 > > > J’en déduit que la charge augmente à cause d’un problème d’interruptions. > Pourtant la charge de trafic UDP n’est pas énorme, surtout par rapport à > l’ancienne installation sur Debian 8 + E1000. > > Nous avons essayé le CPU Pinning => Pas vraiment d’amélioration. > > Nous avons essayé de revenir à E1000 => Amélioration en charge basse mais > pas d'amélioration en charge elevée > > Mes questions : > > - Avez-vous déjà rencontré ce genre de comportements sur le réseau et les > interruption sur Vmware + Linux Debian ? > - Comment être sur que le load average vient bien des interruptions ? > Faut-il mesurer un nombre d’interruptions / seconde pour confirmer ? > - Avez-vous des idées pour faire un bench de VM vierge sur du trafic UDP ? > iperf par exemple entre 2 VM ? > -Avez-vous des idées sur la possible résolution du problème indiqué ? > (j’ai pensé testé en noyau 5.X mais sans conviction) > > Merci pour votre aide, > Fabien > >
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
