Analisi del carico CPU elevato causato da thread del kernel e da irq/softirq: guida pratica con Atop & perf

Elevata CPU-Load dovuta a thread del kernel e irq/softirq è un classico problema operativo: il monitoring mostra Load Average in aumento e servizi lenti, ma in top o htop non si trova un chiaro processo responsabile. In questi casi il lavoro avviene nel kernel (thread del kernel) o nella gestione di interrupt/SoftIRQ. Questo runbook descrive come analizzare la linea temporale con atop e i percorsi del kernel con perf e eBPF, classificare le cause tipiche, derivare misure e pianificare strategie di rollback sicure.

Termini spiegati brevemente

Un breve chiarimento dei termini evita fraintendimenti:

• Load Average: misura il numero medio di thread in esecuzione o in attesa di CPU/I/O. Un Load elevato non significa necessariamente utilizzo completo della CPU; può indicare anche attesa I/O o blocco.
• Ripartizione CPU: user (processi applicativi), system (lavoro del kernel), irq (interrupt hardware), softirq (interrupt software, ossia post-elaborazione), iowait (attesa per I/O di storage) – questa suddivisione è importante per l’analisi delle cause.
• Thread del kernel: processi in contesto kernel come kworker/* o ksoftirqd/*. Eseguono lavoro del kernel e compaiono nelle liste di processi, ma non sono ‚User‑CPU‘.
• IRQ / SoftIRQ: gli IRQ sono interruzioni controllate dall’hardware (interrupt); le SoftIRQ (interrupt software) sono la loro elaborazione in contesto software, spesso per gli stack di rete e I/O (es. NAPI per le reti).

Prerequisiti e quadro di sicurezza

Le analisi richiedono spesso privilegi di root e possono generare carico. Pianificate:

• Coordinamento con Security/Change‑Management, in particolare per perf o eBPF.
• Finestre di misurazione brevi (es. 10–60 secondi) e salvataggio passivo dei log prima delle modifiche.
• Percorso di rollback e documentazione per modifiche a sysctl, unità systemd o flag dei driver.

Prima diagnosi rapida (5 Minuten)

Questa sequenza permette di determinare rapidamente se la causa sono IRQ/SoftIRQ, I/O o VMM‑steal.

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

Interpretazione: se mpstat mostra valori elevati in irq/soft e top elenca thread come ksoftirqd/N o kworker, è probabile che si tratti di elaborazione del kernel/interrupt. Steal indica conflitti di risorse con l’hypervisor.

Atop come strumento per la linea temporale

atop registra metriche storiche in modo più persistente rispetto a top e associa la suddivisione CPU nel tempo. Idealmente esistono già file di log; altrimenti si osserva in live.

# Live-Überwachung
atop 1

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

Cosa osservare: correlazione temporale tra picchi di rete o storage e aumento del tempo in softirq/irq, pattern stabili vs. sporadici e quali thread del kernel sono più attivi.

Focus: perf per i percorsi del kernel

perf mostra a livello di funzione e simbolo dove viene spesa la CPU nel kernel — per esempio nello stack di rete (napi, skb), nel Block‑I/O (nvme, block) o in Netfilter/conntrack. In container o in assenza di simboli di debug i risultati sono limitati.

Preparazione e utilizzo sicuro

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

Se kernel.perf_event_paranoid > 1 è impostato, perf può essere limitato. Le modifiche devono essere concordate con Security. Iniziate senza callgraph (-g) per mantenere basso l’overhead.

Kurzprofil und 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

Esaminate i risultati alla ricerca di hotspot: nomi come napi_poll, __netif_receive_skb_core, xfrm_output o nf_conntrack_* indicano rete/Netfilter; block_rq_issue, nvme_submit_io indicano storage.

Analisi perf approfondita e artefatti

Se la prima registrazione fornisce indicazioni, estendete mirate le analisi. I callgraph (-g) offrono contesto ma aumentano l’overhead di sampling; usateli con cautela.

# 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

Perchr funziona: i profiler a campionamento raccolgono stacktrace dell’esecuzione in corso; gli stack aggregati mostrano i percorsi dominanti. Quando fallisce: con carichi molto brevi o configurazioni di sampling che perdono le signature delle system call (per esempio simboli mancanti).

eBPF und Tracepoints für punktgenaue Fragen

eBPF (Extended Berkeley Packet Filter) permette tracing a bassa latenza nel kernel. Su sistemi di produzione bpftrace 4 una buona scelta per test di ipotesi a breve termine; bpftool aiuta con le metriche. Anche qui vale: coordinamento con la security e durate brevi.

# 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'

Perch usarlo: eBPF misura in modo fine e senza overhead massivo, ideale per verificare, ad es., se napi_poll gira a lungo. Quando non funziona: kernel pii pichi piupipi pipiu uu, piuu pi u portato da RESTrizioni delle policy di distribuzione.

Cause comuni, percorsi di controllo e comandi concreti

1) Netzwerk: PPS, Offload, CNI/Overlay

Molti pacchetti piccoli (alto packets-per-second, PPS) generano SoftIRQ. Verificate drops, errori, offload (TSO/GSO/GRO) e incapsulamento 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

Nota: RPS/RFS tenta di distribuire l’elaborazione su più CPU. Se impostato in modo errato può violare la cache-locality e aumentare le latenze.

2) irqbalance und CPU-Affinität

irqbalance distribuisce gli interrupt. Su CPU isolate o in ambienti NUMA questo può essere subottimale. Controllate smp_affinity per 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

Se un IRQ domina su una singola CPU, un pinning mirato può alleviare. Rischio: pinning errato peggiora throughput o latenza — misurate sempre.

3) Storage: Completion Storms, Treiberfehler

Molte I/Os brevi, timeout o avvisi del driver causano attività di kworker.

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

Errori del driver in dmesg o Kernel‑OOPS sono indicatori critici; spesso qui è necessario un aggiornamento del driver o un rollback del kernel.

Kubernetes: Node‑vs‑Pod‑Unterscheidung und Checks

In Kubernetes cause frequenti: Pod con alto PPS, kube-proxy (NAT/conntrack), comportamento del CNI‑Overlay o del driver CSI. Passaggi importanti:

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

Consiglio: un singolo Pod può provocare elevati Node‑SoftIRQ senza mostrare molta CPU utente. Usate DaemonSet‑diagnoserunner per il profiling a livello di node, non solo kubectl top.

Metriken, Dashboards und Retention

Per poter ripetere la diagnosi, raccogliete queste metriche in modo permanente (Prometheus/Grafana o equivalente): irq/softirq per CPU, contatori NET_RX/NET_TX, PPS, rx_errors/drops, iowait, conteggi thread kworker/ksoftirqd, dimensione conntrack. Garantite una retention adeguata (p.es. 7–30 giorni) per rilevare regressioni dopo aggiornamenti del kernel.

Praxis-Checkliste: Minimaler Prüfpfad

1. Salvare: uptime, uname -a, dmesg, /proc/interrupts, /proc/softirqs.
2. Controllo rapido: mpstat, top -H, ip -s link, ethtool -S, iostat.
3. Atop: identificare correlazioni temporali.
4. Perf (conservativo): breve acquisizione, inizialmente senza -g.
5. eBPF per test di ipotesi: script brevi con bpftrace.
6. Modifiche passo a passo: Offloads, RPS, irqbalance, Pinning – misurare ogni intervento.
7. Pianificare e documentare il rollback.

Wann einfache Maßnahmen nicht helfen

Esistono casi in cui il tuning semplice fallisce e sono necessari interventi più profondi:

• Bug del kernel o del driver: dmesg o perf mostrano percorsi del kernel risolvibili solo con patch o rollback.
• Incompatibilità degli hardware‑offload in ambienti virtualizzati: disattivare gli offload e testare.
• Limiti imposti dall’architettura: p.es. carico massiccio di NAT/conntrack richiede un cambiamento architetturale (LoadBalancer invece di NodePort/SNAT).

Rückfall- und Kommunikationsstrategie

La comunicazione è cruciale: al momento delle modifiche informate SRE/Stakeholder, pianificate finestre di manutenzione se necessario e registrate le metriche prima/dopo. Buone pratiche:

• Documentare le modifiche singolarmente e con timestamp (changelog sul sistema).
• Job di misurazione automatizzati prima/dopo (mpstat, /proc/interrupts, intervalli atop).
• Nel contesto Kubernetes: cordon/drain di un nodo di test, poi modifica e misurazione con simulazione di carico.

Fazit

Un’elevata attività del kernel o irq/softirq è spesso difficile da cogliere, perché il lavoro avviene nel kernel e non nei processi user. Un approccio metodico con analisi rapida di alto livello (mpstat/top/atop), profiling mirato (perf) e tracing puntuale (eBPF) produce ipotesi valide. Misurare, modificare, rollbackare: questa è la sequenza. In Kubernetes è particolarmente importante distinguere tra causa a livello di Pod e causa a livello di Node; una misura sbagliata può avere effetti a livello di cluster.

Questo runbook fornisce gli strumenti e i percorsi di controllo con cui amministratori, system engineer e operator possono analizzare in modo fondato, testare in sicurezza e rollbackare modifiche responsabilmente.

Hohe CPU-Load durch Kernel-Threads und irq/softirq — Betriebs- und Architekturmaßnahmen

Oltre all’analisi acuta, misure operative e architetturali sostenibili sono decisive affinché il problema non si ripeta. Prenda decisioni non solo sulla base di un singolo profilo: sviluppi percorsi permanenti di rilevamento, test e rollback che si integrino nei processi di change e nell’automazione.

Rilevamento continuo e alerting

Un perf‑snapshot a breve termine è utile solo una volta. Configuri alert che rilevino variazioni di SoftIRQ per CPU e aumenti di PPS e che segnalino regressioni in componenti del kernel o del CNI. Esempio di una semplice Prometheus‑Rule:

- 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 }}"

Importante: calibrare le regole sulle vostre baseline per evitare falsi positivi durante carichi stagionali.

Modifiche Canary e strategia di rollout

Le modifiche a sysctl, IRQ‑pinning o offload dovrebbero essere testate in modalità canary su pochi nodi. Procedura pratica:

• Cordon/drain del nodo di test.
• Modifica tramite sysctl‑drop‑in versionato.
• Misurazioni automatizzate (5–15 minuti) rispetto alla baseline.
• Rollback in caso di peggioramento.

Esempio di 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

Automazione e integrazione nel runbook

Integrate script di verifica nella vostra automazione (Ansible, Salt, Terraform per istanze cloud) e versionate le configurazioni sysctl/irqbalance in Git. Un trigger del runbook dovrebbe, dopo gli aggiornamenti del kernel, eseguire automaticamente un breve profiling e scrivere un report di health nel vostro flusso di ticketing. Così evitate sorprese dopo i patch.

Misure architetturali: spostare il carico, non solo applicare patch

Alcuni problemi di SoftIRQ non si risolvono con il tuning; in questi casi passi architetturali sono più efficaci:

• Riducete i PPS a livello di nodo utilizzando load balancer L4/L7 invece di SNAT/NodePort, per evitare pressioni su conntrack.
• Batching e keep‑alive nel software aziendale su misura riducono il numero di pacchetti; verificate le opzioni di socket (TCP_CORK, sendmmsg) in carichi con elevato PPS.
• Allineate le strategie di offload con il vendor cloud o del NIC: l’hardware offload può spostare il carico, ma anche rivelare incompatibilità dei driver.

Rischi, coordinamento con il vendor e artefatti di audit

Raccogliete in modo standardizzato le evidenze (perf raw, flamegraphs, snapshot di atop, tcpdump‑pcap con timestamp) prima di aprire ticket al vendor. Senza artefatti riproducibili la diagnosi si allunga. Per questioni di kernel/driver pianificate rollout del kernel a scaglioni e mantenete le voci di boot (GRUB) per un revert rapido.

In breve: puntate sull’igiene del monitoring, configurazioni versionate, canary‑rollout e verifica architetturale. In questo modo la reazione a carichi elevati del kernel o di irq/softirq diventa pianificabile, misurabile e reversibile — in linea con i processi di change e security esistenti per le vostre soluzioni aziendali digitali.

Per questo tema sono importanti anche l’analisi con Atop e il profiling CPU con Perf. L’articolo inquadra questi aspetti in modo chiaro e mostra cosa conta nella pratica quotidiana.