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.l...@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.fab...@gmail.com > <mailto:frnog.fab...@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 <n...@1g6.biz > <mailto:n...@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.fab...@gmail.com <mailto:frnog.fab...@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/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
