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.fabien@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 guillaume@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.fabien@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
-
Fabien H