Analyser une charge CPU élevée due aux threads du noyau et aux irq/softirq : Manuel pratique Atop & perf

Charge CPU élevée due aux threads du noyau et aux irq/softirq est un problème d’exploitation classique : le monitoring montre des Load Average en hausse et des services lents, mais dans top ou htop on ne trouve pas de processus clairement responsable. Dans ces cas, du travail s’exécute dans le noyau (Kernel‑Threads) ou comme traitement d’interruptions/SoftIRQ. Ce runbook décrit comment, avec atop analyser la chronologie et, avec perf ainsi que eBPF, examiner les chemins du noyau, classer les causes typiques, en déduire des mesures et planifier des stratégies de retour en arrière sûres.

Notions – explication rapide

Une brève harmonisation des termes évite les interprétations erronées :

• Load Average : mesure le nombre moyen de threads en cours d’exécution ou en attente CPU/I/O. Un Load élevé ne signifie pas automatiquement une pleine utilisation CPU ; il peut refléter des temps d’attente I/O ou des blocages.
• Parts CPU : user (processus applicatifs), system (travail noyau), irq (interruptions matérielles), softirq (interruptions logicielles, c.-à-d. post‑traitement), iowait (attente sur I/O de stockage) – cette répartition est importante pour l’analyse des causes.
• Kernel‑Threads : processus dans le contexte noyau comme kworker/* ou ksoftirqd/*. Ils exécutent du travail noyau et apparaissent dans les listes de processus, mais ne sont pas de la « User‑CPU ».
• IRQ / SoftIRQ : les IRQ sont des interruptions pilotées par le matériel ; les SoftIRQ sont leur traitement en contexte logiciel, souvent pour les piles réseau et I/O (par ex. NAPI pour les réseaux).

Prérequis et cadre de sécurité

Les analyses requièrent souvent des droits root et peuvent elles‑mêmes générer de la charge. Prévoyez :

• Coordination avec la sécurité / le Change‑Management, en particulier pour perf ou eBPF.
• Fenêtres de mesure courtes (p. ex. 10–60 secondes) et sauvegarde passive des journaux avant toute modification.
• Chemin de rollback et documentation pour les changements sysctl, les unités systemd ou les flags de pilote.

Diagnostic rapide initial (5 minutes)

Cette séquence permet de déterminer rapidement si IRQ/SoftIRQ, I/O ou VMM‑stealing sont en cause.

uptime
mpstat -P ALL 1 5
top -H -b -n 1 | head -n 80

Interprétation : si mpstat affiche des valeurs élevées en irq/soft et que top liste des threads comme ksoftirqd/N ou kworker, le traitement noyau/interruptions est vraisemblable. Steal indique des conflits de ressources côté hyperviseur.

Atop comme outil de chronologie

atop enregistre des métriques historiques de façon plus persistante que top et répartit la consommation CPU dans le temps. Idéalement, des fichiers de logs existent déjà ; sinon observez en direct.

# Live-Überwachung
atop 1

# Historische Datei lesen (Beispiel)
atop -r /var/log/atop/atop_20260728 -b 10:00 -e 10:30

Points d’attention : corrélation temporelle entre des pics réseau ou stockage et l’augmentation du temps softirq/irq, motifs stables vs sporadiques, et quels Kernel‑Threads sont les plus actifs.

Focus : perf pour les chemins du noyau

perf identifie, au niveau des fonctions et des symboles, où le temps CPU est consommé dans le noyau – p. ex. dans la pile réseau (napi, skb), le bloc I/O (nvme, block), ou Netfilter/conntrack. Dans des conteneurs ou en l’absence de symboles de débogage, les résultats sont limités.

Préparation et utilisation sécurisée

# Prüfen von RESTriktionen
sysctl kernel.perf_event_paranoid
sysctl kernel.kptr_RESTrict
perf --version || true

Si kernel.perf_event_paranoid > 1 est défini, perf peut être RESTreint. Les modifications doivent être coordonnées avec la sécurité. Commencez sans callgraphs (-g) pour limiter l’overhead.

Profil succinct et reporting

# Kurzüberblick (interaktiv, geringerer Overhead)
sudo perf top

# Konservatives Recording: 30s, Sampling-Frequenz 99Hz
sudo perf record -a -F 99 -- sleep 30
sudo perf report --stdio

Lisez les résultats pour identifier les hotspots : des noms comme napi_poll, __netif_receive_skb_core, xfrm_output ou nf_conntrack_* indiquent le réseau/Netfilter ; block_rq_issue, nvme_submit_io pointent vers le storage.

Analyse perf approfondie et artefacts

Si le premier enregistrement donne des indications, étendez ciblé. Les callgraphs (-g) apportent du contexte mais augmentent l’overhead de sampling ; utilisez-les avec prudence.

# Callgraph nur wenn nötig, kurze Dauer
sudo perf record -a -F 249 -g -- sleep 15
sudo perf script > perf.raw
# Optional: FlameGraph-Erzeugung (auf Admin-Workstation)
# git clone https://github.com/brendangregg/FlameGraph.git
# ./FlameGraph/stackcollapse-perf.pl perf.raw > out.folded
# ./FlameGraph/flamegraph.pl out.folded > perf.svg

Pourquoi cela fonctionne : les profilers par sampling collectent des stacktraces de l’exécution en cours ; l’agrégation des stacks met en évidence les chemins dominants. Quand cela échoue : sous une charge très courte ou une configuration de sampling qui masque les signatures d’appels système (p. ex. symboles manquants).

eBPF et tracepoints pour des questions ciblées

eBPF (Extended Berkeley Packet Filter) permet du tracing à faible latence dans le kernel. Pour des systèmes de production, bpftrace est un bon choix pour des tests d’hypothèses à court terme ; bpftool aide pour les métriques. Ici aussi : coordination avec la sécurité et durées d’exécution courtes.

# Beispiel: Zähle Aufrufe von ksoftirqd-Handlern (bpftrace)
sudo bpftrace -e 'tracepoint:irq:softirq_entry { @[comm] = count(); }' -c 'sleep 10'

# Alternativ: Trace network napi poll duration
sudo bpftrace -e 'kprobe:napi_poll { @[comm] = hist(nsecs); }' -c 'sleep 10'

Pourquoi l’utiliser : eBPF mesure de manière fine sans overhead massif, idéal pour vérifier si par exemple napi_poll s’exécute longtemps. Quand ça ne marche pas : kernels anciens sans support BPF ou RESTrictions imposées par les politiques de distribution.

Causes fréquentes, parcours de vérification et commandes concrètes

1) Réseau : PPS, offload, CNI/overlay

Beaucoup de petits paquets (forts Packets-per-Second, PPS) génèrent des SoftIRQs. Vérifiez les drops, errors, les offloads (TSO/GSO/GRO) et la encapsulation CNI.

ip -s link show dev eth0
ethtool -k eth0
ethtool -S eth0 | sed -n '1,200p'
# RPS (Receive Packet Steering) prüfen und setzen
cat /proc/sys/net/core/rps_sock_flow_entries
# Beispiel: RPS für rx-queues setzen (Queue anpassen)
echo 32768 | sudo tee /sys/class/net/eth0/queues/rx-0/rps_cpus

Remarque : RPS/RFS tente de répartir le traitement sur plusieurs CPU. Une mauvaise configuration peut violer la locality du cache et augmenter les latences.

2) irqbalance et affinité CPU

irqbalance répartit les interruptions. Sur des CPUs isolées ou en présence de NUMA, cela peut être sous-optimal. Vérifiez smp_affinity pour chaque IRQ.

sudo systemctl status irqbalance --no-pager
# Beispiel: IRQ-Affinity anzeigen
awk 'NR>1{print $1}' /proc/interrupts | head -n 5 | sed 's/://g' | while read irq; do
  echo "IRQ $irq:"; cat /proc/irq/$irq/smp_affinity_list 2>/dev/null || true
done

Si une IRQ est dominée par une seule CPU, un pinning ciblé peut soulager. Risque : un mauvais pinning peut dégrader le débit ou la latence – toujours mesurer.

3) Storage : completion storms, erreurs de pilote

Beaucoup de petites I/O, des timeouts ou des avertissements de pilotes entraînent une activité kworker.

iostat -x 1 5
nvme list 2>/dev/null || true
dmesg -T | tail -n 200

Les erreurs de pilote dans dmesg ou les Kernel‑OOPS sont des indicateurs critiques ; souvent une mise à jour du pilote ou un rollback du noyau est nécessaire.

Kubernetes : distinction Node vs Pod et vérifications

Dans Kubernetes, les causes fréquentes : un Pod avec un PPS élevé, kube-proxy (NAT/conntrack), un CNI en overlay ou le comportement d’un pilote CSI. Étapes importantes :

kubectl get nodes -o wide
kubectl top nodes
kubectl top pods -A --sort-by=cpu | head -n 30
# Auf dem Node: conntrack-Zähler prüfen
sudo sysctl net.netfilter.nf_conntrack_count
# CNI: prüfen, ob Overlay (vxlan/geneve) läuft
ip link show | grep vxlan -A 2 || true

Conseil : un seul Pod peut provoquer des softirq élevés au niveau du nœud sans pour autant afficher beaucoup de CPU utilisateur. Utilisez des runners de diagnostic via DaemonSet pour le profilage au niveau du nœud, pas seulement kubectl top.

Métriques, tableaux de bord et rétention

Pour pouvoir répéter le diagnostic, collectez ces métriques en continu (Prometheus/Grafana ou équivalent) : irq/softirq par CPU, compteurs NET_RX/NET_TX, PPS, rx_errors/drops, iowait, nombre de threads kworker/ksoftirqd, taille du conntrack. Assurez une rétention suffisante (p. ex. 7–30 jours) pour détecter des régressions après des mises à jour du noyau.

Checklist pratique : chemin de vérification minimal

1. Collecter : uptime, uname -a, dmesg, /proc/interrupts, /proc/softirqs.
2. Vérification rapide : mpstat, top -H, ip -s link, ethtool -S, iostat.
3. Atop : identifier les corrélations temporelles.
4. Perf (conservatif) : enregistrement court, initialement sans -g.
5. eBPF pour tester des hypothèses : bpftrace, scripts courts.
6. Appliquer les changements étape par étape : Offloads, RPS, irqbalance, pinning — mesurer à chaque fois.
7. Planifier et documenter le rollback.

Quand les mesures simples ne suffisent pas

Il existe des cas où des réglages simples échouent et des interventions plus profondes sont nécessaires :

• Bug du noyau ou du pilote : dmesg ou perf mettent en évidence des chemins noyau qui ne peuvent être résolus que par un patch ou un rollback.
• Incompatibilité des offloads matériels en virtualisation : désactiver les offloads et tester.
• Limites liées à l’architecture : p. ex. une charge NAT/conntrack massive nécessite un changement d’architecture (LoadBalancer au lieu de NodePort/SNAT).

Stratégie de retour arrière et de communication

La communication est essentielle : lors des changements, informez les SRE/parties prenantes, planifiez une fenêtre de maintenance si nécessaire et conservez les métriques avant/après. Bonnes pratiques :

• Documenter les changements individuellement et horodatés (changelog sur le système).
• Jobs de mesure automatisés avant/après (mpstat, /proc/interrupts, intervalles atop).
• Dans le contexte Kubernetes : cordon/drain d’un nœud de test, puis modification et mesure avec simulation de charge.

Conclusion

Une forte charge noyau ou irq/softirq est souvent difficile à cerner, car le travail s’effectue dans le noyau plutôt que dans des processus utilisateur. Une approche méthodique avec une analyse rapide de premier niveau (mpstat/top/atop), un profiling ciblé (perf) et un tracing précis (eBPF) fournit des hypothèses solides. Mesurer, modifier, revenir en arrière : telle est la séquence. Dans Kubernetes, la distinction entre la source Pod et la source Node est particulièrement importante ; une mesure inappropriée peut sinon avoir des effets à l’échelle du cluster.

Ce runbook fournit les outils et parcours de vérification permettant aux administrateurs, ingénieurs système et opérateurs d’analyser de manière argumentée, de tester en sécurité et de revenir en arrière de façon responsable sur les changements.

Charge CPU élevée due aux threads noyau et irq/softirq — mesures opérationnelles et d’architecture

Outre l’analyse immédiate, des mesures opérationnelles et architecturales durables sont essentielles pour éviter que le problème ne se reproduise. Ne prenez pas de décisions sur la base d’un seul profil : élaborez des chemins permanents de détection, de test et de rollback qui s’intègrent aux processus de changement et à l’automatisation.

Détection continue et alertes

Un instantané de performance à court terme n’aide qu’une fois. Configurez des alertes qui détectent les variations de SoftIRQ par CPU et l’augmentation du PPS, et qui signalent les régressions dans le noyau ou les composants CNI. Exemple d’une règle Prometheus simple :

- alert: HighSoftirqPerCpu
  expr: increase(node_softirq_total[5m]) / count(node_cpu_seconds_total{mode="system"}) > 1000
  for: 2m
  labels:
    severity: warning
  annotations:
    summary: "Erhöhter SoftIRQ-Anteil auf {{ $labels.instance }}"

Important : calibrez les règles sur vos baselines pour éviter les faux positifs en cas de charge saisonnière.

Tests canary et stratégie de déploiement

Les modifications de sysctl, d’IRQ‑pinning ou d’offloads devraient être testées de manière canary sur quelques nœuds. Processus pratique :

• Cordon/drain du nœud de test.
• Modification via un drop‑in sysctl versionné.
• Mesures automatisées (5–15 minutes) par rapport à la ligne de base.
• Rollback en cas de détérioration.

Exemple sysctl Drop‑in :

# /etc/sysctl.d/99-softirq-tuning.conf
net.core.default_qdisc = fq
net.core.rps_sock_flow_entries = 32768
net.ipv4.conf.all.rp_filter = 1

Automatisation et intégration au runbook

Intégrez des scripts de vérification dans votre automatisation (Ansible, Salt, Terraform pour les instances cloud) et versionnez les configurations sysctl/irqbalance dans Git. Un trigger de runbook devrait, après des mises à jour du noyau, effectuer automatiquement un court profilage et rédiger un rapport de santé dans votre flux de ticketing. Ainsi vous évitez les surprises après des patchs.

Mesures d’architecture : déporter la charge, ne pas se limiter à des correctifs

Certains problèmes de SoftIRQ ne se résolvent pas par du tuning ; des mesures architecturales sont alors plus efficaces :

• Réduisez le PPS au niveau du nœud en utilisant des load balancers L4/L7 plutôt que SNAT/NodePort, afin d’éviter la pression sur conntrack.
• Le batching et le keep‑alive dans le logiciel métier personnalisé réduisent le nombre de paquets ; vérifiez les options de socket (TCP_CORK, sendmmsg) en cas de forte charge PPS.
• Concertez les stratégies d’offloading avec le fournisseur cloud ou le fournisseur NIC : l’offload matériel peut déplacer la charge, mais aussi révéler des incompatibilités de pilotes.

Risques, coordination avec les fournisseurs et artefacts d’audit

Collectez de manière standardisée les constatations (perf raw, flamegraphs, captures atop, tcpdump‑pcap avec horodatages) avant d’ouvrir des tickets auprès des fournisseurs. Sans artefacts reproductibles, le diagnostic s’allonge. Pour les questions de noyau/pilote, planifiez des rollouts de noyau par paliers et conservez les entrées de boot (GRUB) pour un revert rapide.

En bref : misez sur une hygiène de monitoring, des configurations versionnées, des rollouts canary et une revue architecturale. Ainsi, la réaction à une forte charge kernel ou irq/softirq devient planifiable, mesurable et réversible — en accord avec vos processus existants de gestion des changements et de sécurité pour vos solutions d’entreprise numériques.

L’analyse Atop et le profilage CPU avec perf sont également importants pour ce sujet. Cet article situe ces aspects de manière claire et montre ce qui importe au quotidien.