OK j'avais mis de côté cela parce que cela parlait de TCP mais je vais tester, merci !
Le ven. 10 sept. 2021 à 12:15, Jean-Yves LENHOF <jean-y...@lenhof.eu.org> a écrit : > Le 2021-09-10 11:55, Fabien H 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 > > Deux KBs qui parlent de LRO, ça pourrait valoir le coup de tester : > https://kb.vmware.com/s/article/1027511 > https://kb.vmware.com/s/article/2077393 > > > -- > Jean-Yves LENHOF > jean-y...@lenhof.eu.org >
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
