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.ponz...@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.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> 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> 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> >>> *À: *"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/ >
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
