Donc j'ai regardé avec htop, très intéressant, au niveau irq, je n'ai vu que des soft-irq et sur 2 CPU (#4 et #5) : je ne sais pas pourquoi ces CPU, je ne vois pas dans /proc/interrupts ce qui pourrait expliquer cela..
> 10 septembre 2021 12:21 "Fabien H" <frnog.fab...@gmail.com> a écrit: > > > D'accord je vais jeter un oeil à cela merci. > > > > irqbalance est bien installé, d'ailleurs je vois remonter les process > ksoftirqd/2 et ksoftirqd/3 > > lors des fortes charges. > > > > J'ai lu dans la littérature que de toute façon, les interrupt d'une > carte réseau ne seraient pas > > réparties par irqbalance mais seraient justement tout le temps traité > par le même CPU virtuel pour > > des raisons de performance..? > > Je ne sais pas si il y a un comportement spécifique sur du virtuel mais > avec un OS sur un hôte physique il est important que les IRQ soit réparties > sur l'ensemble des cœurs sinon on fini par perdre des connexions car un > cœur sature en passant son temps a gérer les interruptions alors que les > autre se tournent les pouces. > > Le tunning nginx (si je ne me trompe pas) est bon ? Par exemple > worker_rlimit_nofile, worker_connections ou bien worker_processes, > worker_cpu_affinity. Logiquement vous avez gardé la même conf je suppose > > Par contre le tuning de la stack réseau n'a peut etre pas été reporté sur > le nouvel OS ? (somaxconn, ip_local_port_range, et si il y a aussi du tcp > tcp_fin_timeout..) ? > > > > > Le ven. 10 sept. 2021 à 12:16, Guillaume Vassal <guilla...@vass.al> a > écrit : > > > >> Bonjour, > >> > >> J'ai eu ce genre problème sur de la machine physique qui encaisse > vraiment beaucoup de trafic, mais > >> ça doit être valable sur du virtuel. > >> > >> Dans un premier temps, pour voir si les IRQ sont mal réparties sur les > différents cœurs sans se > >> prendre la tête tu peux utiliser simplement htop > F2 > Display Options > > [x] Detailed CPU time > >> (.....) > >> > >> De visu si tout s'empile sur seulement sur certains cœur c'est qu'il y > a surement un problème de > >> répartition. > >> > >> Une piste peut être de vérifier que le service irqbalnce est bien > installé et démarré. Il fait le > >> café tout seul en théorie > >>> systemctl status irqbalance.service > >> > >> Cdt, > >> -- > >> Guillaume Vassal > >> > >> 10 septembre 2021 11:55 "Fabien H" <frnog.fab...@gmail.com> 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 >
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
