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-yves@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-yves@lenhof.eu.org