VMWARE / Debian 10 / Problème interruptions sur cartes réseau
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
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
Hello, Je cherche si je trouve d'autres idées mais une idée serait peut-être de regarder la version hardware présentée au niveau de tes VMs ("Virtual Machine Hardware Version" au niveau VMWARE) Cordialement, -- Jean-Yves LENHOF jean-yves@lenhof.eu.org
Merci pour le retour Voici les informations dans le VMX : config.version = "8" virtualHW.version = "11" Bien entendu les VMWare Tools sont installés Le ven. 10 sept. 2021 à 12:09, 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
Hello,
Je cherche si je trouve d'autres idées mais une idée serait peut-être de regarder la version hardware présentée au niveau de tes VMs ("Virtual Machine Hardware Version" au niveau VMWARE)
Cordialement,
-- Jean-Yves LENHOF jean-yves@lenhof.eu.org
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
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
Hello Fabien, Si j'ai bien suivi, au final avec exactement le même environnement sauf changement du noyau linux lié à la debian, si tout le reste est dans les mêmes conditions de conf, le comportement est moins bon ? l'applicatif lui même est en version identique dans les 2 cas ? (non je n'ai pas reconnu lol, ça pourrait être de la voip, du gaming, du p2p ...) Si tout le reste est identique tu peux en effet jouer sur les versions du noyau et remettre la version du noyau de debian 8 pour vérifier que tu retrouves tes billes, il y a certainement du tuning supplémentaire au niveau de la conf du noyau dans ton cas spécifique de charge. En général le tuning par défaut du noyau est correct pour du 1Gbit/s, si tu as plus que 1Gbits/s en général tu as quelques buffers, files, etc à configurer. A+ Nicolas De: "Fabien H" <frnog.fabien@gmail.com> À: "frsag" <frsag@frsag.org> Envoyé: Vendredi 10 Septembre 2021 11:55:38 Objet: [FRsAG] VMWARE / Debian 10 / Problème interruptions sur cartes réseau BQ_BEGIN 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/ BQ_END
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 Le ven. 10 sept. 2021 à 13:36, Nicolas Parpandet <npa@1g6.biz> a écrit :
Hello Fabien,
Si j'ai bien suivi, au final avec exactement le même environnement sauf changement du noyau linux lié à la debian, si tout le reste est dans les mêmes conditions de conf, le comportement est moins bon ?
l'applicatif lui même est en version identique dans les 2 cas ? (non je n'ai pas reconnu lol, ça pourrait être de la voip, du gaming, du p2p ...)
Si tout le reste est identique tu peux en effet jouer sur les versions du noyau et remettre la version du noyau de debian 8 pour vérifier que tu retrouves tes billes, il y a certainement du tuning supplémentaire au niveau de la conf du noyau dans ton cas spécifique de charge.
En général le tuning par défaut du noyau est correct pour du 1Gbit/s, si tu as plus que 1Gbits/s en général tu as quelques buffers, files, etc à configurer.
A+
Nicolas
------------------------------
*De: *"Fabien H" <frnog.fabien@gmail.com> *À: *"frsag" <frsag@frsag.org> *Envoyé: *Vendredi 10 Septembre 2021 11:55:38 *Objet: *[FRsAG] VMWARE / Debian 10 / Problème interruptions sur cartes réseau
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/
Salut, Avez vous joué sur les CPU allocation côté vmware et aussi sur les process par coeurs côté debian ? Je ne connais pas du tout le fonctionnement de cet application. Mais sur un base de type Informix, il est important de spécifier chaque vcpu sur chaque coeur pour avoir des perf stable et bonne. Le ven. 10 sept. 2021 à 14:04, Fabien H <frnog.fabien@gmail.com> a écrit :
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
Le ven. 10 sept. 2021 à 13:36, Nicolas Parpandet <npa@1g6.biz> a écrit :
Hello Fabien,
Si j'ai bien suivi, au final avec exactement le même environnement sauf changement du noyau linux lié à la debian, si tout le reste est dans les mêmes conditions de conf, le comportement est moins bon ?
l'applicatif lui même est en version identique dans les 2 cas ? (non je n'ai pas reconnu lol, ça pourrait être de la voip, du gaming, du p2p ...)
Si tout le reste est identique tu peux en effet jouer sur les versions du noyau et remettre la version du noyau de debian 8 pour vérifier que tu retrouves tes billes, il y a certainement du tuning supplémentaire au niveau de la conf du noyau dans ton cas spécifique de charge.
En général le tuning par défaut du noyau est correct pour du 1Gbit/s, si tu as plus que 1Gbits/s en général tu as quelques buffers, files, etc à configurer.
A+
Nicolas
------------------------------
*De: *"Fabien H" <frnog.fabien@gmail.com> *À: *"frsag" <frsag@frsag.org> *Envoyé: *Vendredi 10 Septembre 2021 11:55:38 *Objet: *[FRsAG] VMWARE / Debian 10 / Problème interruptions sur cartes réseau
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/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour Jérôme, Oui je pense avoir fait le CPU pinning correctement dans Paramètres de la VM, onglet ressources, CPU Avancé, j'ai mis Partage du noyau d'hyperthread = Internet & Planification affinité = 0-7 pour que 8 CPU Physiques sont affectés aux 8 vCPU (pas de coeur virtuel, uniquement des CPU virtuels).. Mais pas d'amélioration. Les process par coeur côté debian, je n'ai pas beaucoup joué dessus car j'ai eu du mal à comprendre.
Je ne sais pas si ça a été suggéré, mais à aucun moment Fabien ne semble vouloir incriminer la Debian 10. Donc Fabien, Il faudrait comparer une Debian 8 et 10 sur du bare-metal, parce que ça ne serait pas la première fois qu’il y aurait une régression (ou au moins un changement de « paradigme » ) lors d’une mise à jour de Linux. Et au niveau opérationnel, à part vous affoler, ça pose un problème ? Ca se voit rapidement sur de la voix :) C’est peut-être juste la méthode de calcul de la charge qui a été changée.
Le 10 sept. 2021 à 14:52, Jerome Lien <jerome.lien@gmail.com> a écrit :
Salut,
Avez vous joué sur les CPU allocation côté vmware et aussi sur les process par coeurs côté debian ? Je ne connais pas du tout le fonctionnement de cet application. Mais sur un base de type Informix, il est important de spécifier chaque vcpu sur chaque coeur pour avoir des perf stable et bonne.
Le ven. 10 sept. 2021 à 14:04, Fabien H <frnog.fabien@gmail.com <mailto:frnog.fabien@gmail.com>> a écrit : 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
Le ven. 10 sept. 2021 à 13:36, Nicolas Parpandet <npa@1g6.biz <mailto:npa@1g6.biz>> a écrit : Hello Fabien,
Si j'ai bien suivi, au final avec exactement le même environnement sauf changement du noyau linux lié à la debian, si tout le reste est dans les mêmes conditions de conf, le comportement est moins bon ?
l'applicatif lui même est en version identique dans les 2 cas ? (non je n'ai pas reconnu lol, ça pourrait être de la voip, du gaming, du p2p ...)
Si tout le reste est identique tu peux en effet jouer sur les versions du noyau et remettre la version du noyau de debian 8 pour vérifier que tu retrouves tes billes, il y a certainement du tuning supplémentaire au niveau de la conf du noyau dans ton cas spécifique de charge.
En général le tuning par défaut du noyau est correct pour du 1Gbit/s, si tu as plus que 1Gbits/s en général tu as quelques buffers, files, etc à configurer.
A+
Nicolas
De: "Fabien H" <frnog.fabien@gmail.com <mailto:frnog.fabien@gmail.com>> À: "frsag" <frsag@frsag.org <mailto:frsag@frsag.org>> Envoyé: Vendredi 10 Septembre 2021 11:55:38 Objet: [FRsAG] VMWARE / Debian 10 / Problème interruptions sur cartes réseau 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/ <http://www.frsag.org/> _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ <http://www.frsag.org/> _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour David, oui effectivement il faudra que je teste sur du bare-metal, remonter l'OS complet :-( Au niveau opérationnel, pas d'impact particulier car après avoir fait les tests de pinning CPU non concluants à 8 CPU, j'ai augmenté le nombre de vCPU à 12 donc même si un load temporaire de 6 ou 8 se produit, ras sur la voix. Mais ça ne rassure pas.. Au niveau des stats vmware de la VM, utilisation CPU en % : 5%, utilisation CPU en Mhz : 1400 Mhz => courbe constante, pas de pics ! 1400 Mhz = Ca correspond à l'ancienne infra sur Debian 8 qui elle a un load average en forte charge entre 0,1 et 0,5, max 0,8. Donc ça va dans le sens effectivement de la théorie que le load average serait peut-être artificiel sur la Debian 10 ..? Le ven. 10 sept. 2021 à 15:06, David Ponzone <david.ponzone@gmail.com> a écrit :
Je ne sais pas si ça a été suggéré, mais à aucun moment Fabien ne semble vouloir incriminer la Debian 10.
Donc Fabien,
Il faudrait comparer une Debian 8 et 10 sur du bare-metal, parce que ça ne serait pas la première fois qu’il y aurait une régression (ou au moins un changement de « paradigme » ) lors d’une mise à jour de Linux. Et au niveau opérationnel, à part vous affoler, ça pose un problème ? Ca se voit rapidement sur de la voix :) C’est peut-être juste la méthode de calcul de la charge qui a été changée.
Le 10 sept. 2021 à 14:52, Jerome Lien <jerome.lien@gmail.com> a écrit :
Salut,
Avez vous joué sur les CPU allocation côté vmware et aussi sur les process par coeurs côté debian ? Je ne connais pas du tout le fonctionnement de cet application. Mais sur un base de type Informix, il est important de spécifier chaque vcpu sur chaque coeur pour avoir des perf stable et bonne.
Le ven. 10 sept. 2021 à 14:04, Fabien H <frnog.fabien@gmail.com> a écrit :
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
Le ven. 10 sept. 2021 à 13:36, Nicolas Parpandet <npa@1g6.biz> a écrit :
Hello Fabien,
Si j'ai bien suivi, au final avec exactement le même environnement sauf changement du noyau linux lié à la debian, si tout le reste est dans les mêmes conditions de conf, le comportement est moins bon ?
l'applicatif lui même est en version identique dans les 2 cas ? (non je n'ai pas reconnu lol, ça pourrait être de la voip, du gaming, du p2p ...)
Si tout le reste est identique tu peux en effet jouer sur les versions du noyau et remettre la version du noyau de debian 8 pour vérifier que tu retrouves tes billes, il y a certainement du tuning supplémentaire au niveau de la conf du noyau dans ton cas spécifique de charge.
En général le tuning par défaut du noyau est correct pour du 1Gbit/s, si tu as plus que 1Gbits/s en général tu as quelques buffers, files, etc à configurer.
A+
Nicolas
------------------------------
*De: *"Fabien H" <frnog.fabien@gmail.com> *À: *"frsag" <frsag@frsag.org> *Envoyé: *Vendredi 10 Septembre 2021 11:55:38 *Objet: *[FRsAG] VMWARE / Debian 10 / Problème interruptions sur cartes réseau
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/
_______________________________________________ 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/
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@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
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@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@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
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@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-frsag@neptune.fr<mailto:fhe-frsag@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@gmail.com<mailto:frnog.fabien@gmail.com>> À: "frsag" <frsag@frsag.org<mailto: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
Bonjour Remi, Intéressant mitigations=off je vais essayer Merci Le ven. 10 sept. 2021 à 16:36, Rémy Duchet <remy@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@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-frsag@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@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
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@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@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@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-frsag@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@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/
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@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@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@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@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-frsag@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@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/
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@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@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@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@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@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-frsag@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@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/
A ce stade là, tu te demandes pas si la virtu en vaut la chandelle ? Tu oses faire tourner d’autres VM assez consommatrice de CPU sur le même HV ?
Le 15 sept. 2021 à 17:29, Fabien H <frnog.fabien@gmail.com> a écrit :
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 :
Le seul intérêt que j'ai trouvé sur ce projet avec la virtu c'est que j'ai pu cloné l'environnement complexe à l'identique (hors IP) à 2 endroits distants en moins de 1H d'installation sur un ESXI neuf.. + le backup Veeam pour la restauration rapide Après non, en fait le load semble elevé mais comme tu disais il me semble, le CPU physique n'est pas si elevé, comme si la méthode de calcul du Load avait changé.. Et puis je ne fais un pining que sur 8 / 64 CPU. Je considère que c'est moins chiant que d'installer un serveur physique à côté Mais si pas le choix un jour sur la charge, il faudra que je le fasse en physique effectivement :-) Le mer. 15 sept. 2021 à 17:36, David Ponzone <david.ponzone@gmail.com> a écrit :
A ce stade là, tu te demandes pas si la virtu en vaut la chandelle ? Tu oses faire tourner d’autres VM assez consommatrice de CPU sur le même HV ?
Le 15 sept. 2021 à 17:29, Fabien H <frnog.fabien@gmail.com> a écrit :
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 :
Hello, J'ai fait cette upgrade il y a quelques années. Le soft, c'est freeswitch ou asterisk ? En passant d'un kernel 3.16 (Debian 8) à un kernel 4.19 (Debian 10), j'avais aussi constaté une hausse des loads, de façon globale, sur toutes les VMs. En passant d'un freeswitch 1.2 à 1.4 (ou 1.6), j'ai également constaté une hausse des loads (et de la consommation de RAM). Mes conclusions : - le calcul des loads a changé dans le kernel, - FS consomme plus de ressources dans les dernières versions. Toutefois, bien que le load kernel augmente (freeswitch ayant une priorité à -16, ça va vite), le "min idle cpu" dans FS ne bouge pas. Donc du point de vue du soft, RAS. Depuis, je suis passé sur proxmox, les loads ont rebaissé. Le "min cpu idle" lui n'a pas bougé. Cdlt FC ________________________________ From: FRsAG <frsag-bounces@frsag.org> on behalf of Fabien H <frnog.fabien@gmail.com> Sent: Friday, September 10, 2021, 11:56 To: frsag@frsag.org Subject: [FRsAG] VMWARE / Debian 10 / Problème interruptions sur cartes réseau 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
Bonjour Florent, Freeswitch :-) 1.6 à 1.10 min idle cpu 0.00/99.77 sur 1.6 min idle cpu 0.00/99.33 sur 1.10 J'ai du mal à interpreter ces valeurs, ça veut dire quoi ? C'est lié à ça https://freeswitch.org/confluence/display/FREESWITCH/min-idle-cpu ? Merci Le ven. 10 sept. 2021 à 16:04, Florent CHAUVEAU <florent.chauveau@gmail.com> a écrit :
Hello,
J'ai fait cette upgrade il y a quelques années.
Le soft, c'est freeswitch ou asterisk ?
En passant d'un kernel 3.16 (Debian 8) à un kernel 4.19 (Debian 10), j'avais aussi constaté une hausse des loads, de façon globale, sur toutes les VMs.
En passant d'un freeswitch 1.2 à 1.4 (ou 1.6), j'ai également constaté une hausse des loads (et de la consommation de RAM).
Mes conclusions : - le calcul des loads a changé dans le kernel, - FS consomme plus de ressources dans les dernières versions.
Toutefois, bien que le load kernel augmente (freeswitch ayant une priorité à -16, ça va vite), le "min idle cpu" dans FS ne bouge pas. Donc du point de vue du soft, RAS.
Depuis, je suis passé sur proxmox, les loads ont rebaissé. Le "min cpu idle" lui n'a pas bougé.
Cdlt
FC
------------------------------ *From:* FRsAG <frsag-bounces@frsag.org> on behalf of Fabien H < frnog.fabien@gmail.com> *Sent:* Friday, September 10, 2021, 11:56 *To:* frsag@frsag.org *Subject:* [FRsAG] VMWARE / Debian 10 / Problème interruptions sur cartes réseau
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
Ton min idle cpu est paramétré à zéro. Tu pourrais mettre 10 ou 20. Si le idle passe en dessous de la valeur configurée, FS refuse les appels. Ça vaut le coup si tu process le media sur FS. Actuellement, du point de vue de freeswitch, ton cpu est idle à 99.33%. Autrement dit, ras :) FC ________________________________ From: FRsAG <frsag-bounces@frsag.org> on behalf of Fabien H <frnog.fabien@gmail.com> Sent: Friday, September 10, 2021 4:12:24 PM To: frsag@frsag.org <frsag@frsag.org> Subject: Re: [FRsAG] VMWARE / Debian 10 / Problème interruptions sur cartes réseau Bonjour Florent, Freeswitch :-) 1.6 à 1.10 min idle cpu 0.00/99.77 sur 1.6 min idle cpu 0.00/99.33 sur 1.10 J'ai du mal à interpreter ces valeurs, ça veut dire quoi ? C'est lié à ça https://freeswitch.org/confluence/display/FREESWITCH/min-idle-cpu ? Merci Le ven. 10 sept. 2021 à 16:04, Florent CHAUVEAU <florent.chauveau@gmail.com<mailto:florent.chauveau@gmail.com>> a écrit : Hello, J'ai fait cette upgrade il y a quelques années. Le soft, c'est freeswitch ou asterisk ? En passant d'un kernel 3.16 (Debian 8) à un kernel 4.19 (Debian 10), j'avais aussi constaté une hausse des loads, de façon globale, sur toutes les VMs. En passant d'un freeswitch 1.2 à 1.4 (ou 1.6), j'ai également constaté une hausse des loads (et de la consommation de RAM). Mes conclusions : - le calcul des loads a changé dans le kernel, - FS consomme plus de ressources dans les dernières versions. Toutefois, bien que le load kernel augmente (freeswitch ayant une priorité à -16, ça va vite), le "min idle cpu" dans FS ne bouge pas. Donc du point de vue du soft, RAS. Depuis, je suis passé sur proxmox, les loads ont rebaissé. Le "min cpu idle" lui n'a pas bougé. Cdlt FC ________________________________ From: FRsAG <frsag-bounces@frsag.org<mailto:frsag-bounces@frsag.org>> on behalf of Fabien H <frnog.fabien@gmail.com<mailto:frnog.fabien@gmail.com>> Sent: Friday, September 10, 2021, 11:56 To: frsag@frsag.org<mailto:frsag@frsag.org> Subject: [FRsAG] VMWARE / Debian 10 / Problème interruptions sur cartes réseau 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
OK Florent, donc ça semble confirmer le fait que le phénomène constaté sur le load average n'est pas anormal en soi sur cette version de debian et de FS et n'empêche pas l'applicatif de fonctionner.. Je vais relever les valeurs d'alerte sur le monitoring et essayer d'oublier un peu ça pendant 1 ou 2 semaines, on verra bien si ça tient :-) Merci pour l'aide Le ven. 10 sept. 2021 à 16:29, Florent CHAUVEAU <florent.chauveau@gmail.com> a écrit :
Ton min idle cpu est paramétré à zéro. Tu pourrais mettre 10 ou 20. Si le idle passe en dessous de la valeur configurée, FS refuse les appels. Ça vaut le coup si tu process le media sur FS.
Actuellement, du point de vue de freeswitch, ton cpu est idle à 99.33%. Autrement dit, ras :)
FC ------------------------------ *From:* FRsAG <frsag-bounces@frsag.org> on behalf of Fabien H < frnog.fabien@gmail.com> *Sent:* Friday, September 10, 2021 4:12:24 PM *To:* frsag@frsag.org <frsag@frsag.org> *Subject:* Re: [FRsAG] VMWARE / Debian 10 / Problème interruptions sur cartes réseau
Bonjour Florent,
Freeswitch :-)
1.6 à 1.10
min idle cpu 0.00/99.77 sur 1.6 min idle cpu 0.00/99.33 sur 1.10
J'ai du mal à interpreter ces valeurs, ça veut dire quoi ? C'est lié à ça https://freeswitch.org/confluence/display/FREESWITCH/min-idle-cpu ?
Merci
Le ven. 10 sept. 2021 à 16:04, Florent CHAUVEAU < florent.chauveau@gmail.com> a écrit :
Hello,
J'ai fait cette upgrade il y a quelques années.
Le soft, c'est freeswitch ou asterisk ?
En passant d'un kernel 3.16 (Debian 8) à un kernel 4.19 (Debian 10), j'avais aussi constaté une hausse des loads, de façon globale, sur toutes les VMs.
En passant d'un freeswitch 1.2 à 1.4 (ou 1.6), j'ai également constaté une hausse des loads (et de la consommation de RAM).
Mes conclusions : - le calcul des loads a changé dans le kernel, - FS consomme plus de ressources dans les dernières versions.
Toutefois, bien que le load kernel augmente (freeswitch ayant une priorité à -16, ça va vite), le "min idle cpu" dans FS ne bouge pas. Donc du point de vue du soft, RAS.
Depuis, je suis passé sur proxmox, les loads ont rebaissé. Le "min cpu idle" lui n'a pas bougé.
Cdlt
FC
------------------------------ *From:* FRsAG <frsag-bounces@frsag.org> on behalf of Fabien H < frnog.fabien@gmail.com> *Sent:* Friday, September 10, 2021, 11:56 *To:* frsag@frsag.org *Subject:* [FRsAG] VMWARE / Debian 10 / Problème interruptions sur cartes réseau
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
participants (9)
-
David Ponzone -
Fabien H -
Florent CHAUVEAU -
Frederic Hermann -
Inulogic - Gurvan Rottier-Ripoche -
Jean-Yves LENHOF -
Jerome Lien -
Nicolas Parpandet -
Rémy Duchet