Analizar alta carga de CPU por hilos del kernel e irq/softirq: Guía práctica de Atop & perf

Alta carga de CPU por kernel-threads e irq/softirq es un problema clásico de operación: el monitoring muestra Load Averages crecientes y servicios lentos, pero en top o htop no aparece un proceso culpable claro. En esos casos el trabajo se ejecuta en el kernel (Kernel‑Threads) o como procesamiento de interrupt/softIRQ. Este runbook describe cómo, con atop analizar la línea temporal y con perf así como eBPF las rutas del kernel, clasificar causas típicas, derivar medidas y planificar estrategias de retroceso seguras.

Términos brevemente explicados

Una aclaración breve de términos evita malas interpretaciones:

• Load Average: Mide el número medio de hilos que están ejecutándose o esperando por CPU/I/O. Un Load alto no implica automáticamente CPU al 100%; también puede deberse a esperas por I/O o bloqueos.
• CPU-Anteile: user (procesos de aplicación), system (trabajo en kernel), irq (interrupciones hardware), softirq (interrupciones software, es decir, procesamiento posterior), iowait (espera por I/O de almacenamiento) – esta distribución es clave para el análisis de causa.
• Kernel-Threads: Procesos en contexto kernel como kworker/* o ksoftirqd/*. Ejecutan trabajo del kernel y aparecen en listas de procesos, pero no son „User‑CPU“.
• IRQ / SoftIRQ: IRQ son interrupciones iniciadas por hardware (interrupts); SoftIRQs (interrupciones software) son su procesamiento en contexto software, frecuentemente para pilas de red e I/O (p. ej. NAPI para networking).

Requisitos previos y marco de seguridad

Los análisis suelen requerir privilegios root y pueden generar carga por sí mismos. Planifique:

• Alineamiento con Security/Change‑Management, especialmente al usar perf o eBPF.
• Ventanas de medición cortas (p. ej. 10–60 segundos) y copia pasiva de logs antes de cambios.
• Ruta de rollback y documentación para cambios en sysctl, systemd‑Units o flags de drivers.

Diagnóstico rápido inicial (5 Minuten)

Esta secuencia permite determinar rápidamente si IRQ/SoftIRQ, I/O o VMM‑stealing son la causa.

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

Interpretación: Si mpstat muestra valores elevados en irq/soft y top lista hilos como ksoftirqd/N o kworker, es probable que se trate de procesamiento del kernel/interrupt. Steal indica conflictos de recursos con el hipervisor.

Atop als Zeitachsenwerkzeug

atop registra métricas históricas de forma más persistente que top y distribuye el desglose de CPU a lo largo del tiempo. Idealmente ya existen archivos de log; si no, observe en vivo.

# Live-Überwachung
atop 1

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

En qué fijarse: correlación temporal entre picos de red o almacenamiento y aumento de tiempo softirq/irq, patrones estables vs. esporádicos y qué kernel‑threads están más activos.

Fokus: perf für Kernelpfade

perf muestra, a nivel de funciones y símbolos, dónde se consume tiempo de CPU en el kernel – por ejemplo en la pila de red (napi, skb), I/O de bloque (nvme, block), o Netfilter/conntrack. En contenedores o sin símbolos de depuración los resultados están limitados.

Vorbereitung und sichere Nutzung

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

Si kernel.perf_event_paranoid > 1 está configurado, perf puede estar RESTringido. Los cambios deben coordinarse con Security. Comience sin Callgraphs (-g) para mantener bajo el overhead.

Perfil breve e informes

# 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

Lea los resultados en busca de hotspots: nombres como napi_poll, __netif_receive_skb_core, xfrm_output o nf_conntrack_* indican red/Netfilter; block_rq_issue, nvme_submit_io indican almacenamiento.

Análisis avanzado de perf y artefactos

Si la primera grabación aporta indicios, amplíela de forma selectiva. Los callgraphs (-g) aportan contexto, pero aumentan el overhead de muestreo; úselos con prudencia.

# 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

Por qué funciona: los sampling profilers recopilan stacktraces de la ejecución en curso; las pilas agregadas muestran las rutas dominantes. Cuándo falla: con carga muy corta o configuraciones de muestreo que tragan las firmas de system call (p. ej. símbolos ausentes).

eBPF y tracepoints para preguntas puntuales

eBPF (Extended Berkeley Packet Filter) permite tracing de baja latencia en el kernel. Para sistemas productivos, bpftrace es una buena opción para pruebas de hipótesis de corta duración; bpftool ayuda con métricas. Aquí también aplica: coordinar con seguridad y mantener tiempos de ejecución cortos.

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

Por qué usarlo: eBPF mide de forma muy granular sin overhead masivo, ideal para comprobar si, p. ej., napi_poll se ejecuta durante mucho tiempo. Cuándo no funciona: kernels antiguos sin soporte BPF o RESTricciones impuestas por las políticas de la distribución.

Causas frecuentes, rutas de comprobación y comandos concretos

1) Red: PPS, offload, CNI/Overlay

Muchos paquetes pequeños (alto Packets-per-Second, PPS) generan SoftIRQs. Compruebe drops, errores, offloads (TSO/GSO/GRO) y el encapsulado de 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 intenta distribuir el procesamiento entre varias CPUs. Si se configura incorrectamente puede romper la localidad de caché y aumentar latencias.

2) irqbalance y afinidad de CPU

irqbalance distribuye las interrupciones. En CPUs aisladas o entornos NUMA puede ser subóptimo. Compruebe smp_affinity por 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 un IRQ domina en una sola CPU, un pinning dirigido puede aliviar la carga. Riesgo: un pinning incorrecto puede empeorar el throughput o la latencia — mida siempre.

3) Almacenamiento: Completion Storms, errores de controlador

Muchas E/S cortas, timeouts o advertencias del controlador provocan actividad de kworker.

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

Los errores de controlador en dmesg o Kernel‑OOPS son indicadores críticos; a menudo aquí se necesita una actualización del controlador o un rollback del kernel.

Kubernetes: Distinción Node vs Pod y comprobaciones

En Kubernetes las causas frecuentes son: pods con alto PPS, kube-proxy NAT/conntrack, CNI‑overlay o comportamientos de controladores CSI. Pasos importantes:

kubectl get nodes -o wide
kubectl top nodes
kubectl top pods -A --sort-by=cpu | head -n 30
# En el nodo: comprobar el contador de conntrack
sudo sysctl net.netfilter.nf_conntrack_count
# CNI: comprobar si el overlay (vxlan/geneve) está activo
ip link show | grep vxlan -A 2 || true

Consejo: Un único pod puede provocar altas softIRQ a nivel de nodo sin mostrar mucha CPU de usuario. Utilice DaemonSet‑Diagnoserunner para perfilado a nivel de nodo, no solo kubectl top.

Métricas, dashboards y retención

Para que el diagnóstico pueda repetirse, recopile estas métricas de forma persistente (Prometheus/Grafana u otras similares): irq/softirq por CPU, contadores NET_RX/NET_TX, PPS, rx_errors/drops, iowait, recuentos de hilos kworker/ksoftirqd, tamaño de conntrack. Asegure una retención adecuada (p. ej. 7–30 días) para poder detectar regresiones tras actualizaciones del kernel.

Lista de comprobación práctica: Ruta mínima de verificación

1. Respaldar: uptime, uname -a, dmesg, /proc/interrupts, /proc/softirqs.
2. Chequeo rápido: mpstat, top -H, ip -s link, ethtool -S, iostat.
3. Atop: identificar correlaciones temporales.
4. Perf (conservador): grabación corta, inicialmente sin -g.
5. eBPF para pruebas de hipótesis: bpftrace con scripts cortos.
6. Realizar cambios de forma incremental: Offloads, RPS, irqbalance, pinning – medir tras cada uno.
7. Planificar y documentar el rollback.

Cuando las medidas simples no funcionan

Hay casos en los que los ajustes sencillos fallan y se requieren intervenciones más profundas:

• Bug del kernel o del controlador: dmesg o perf muestran rutas del kernel que solo se resuelven con un parche o rollback.
• Incompatibilidad de offload de hardware en virtualización: desactivar los offloads y probar.
• Límites impuestos por la arquitectura: p. ej., una carga masiva de NAT/conntrack exige un cambio de arquitectura (LoadBalancer en lugar de NodePort/SNAT).

Estrategia de retroceso y comunicación

La comunicación es crucial: al realizar cambios informe a SRE/Stakeholders, planifique ventanas de mantenimiento si es necesario y conserve métricas antes/después. Buenas prácticas:

• Documentar los cambios de uno en uno con marca temporal (changelog en el sistema).
• Trabajos de medición automatizados antes/después (mpstat, /proc/interrupts, intervalos de atop).
• En el contexto de Kubernetes: cordon/drain de un nodo de prueba, luego cambio y medición con simulación de carga.

Conclusión

Una elevada carga del kernel o de irq/softirq suele ser difícil de capturar porque el trabajo se realiza en el kernel en lugar de en procesos de usuario. Un enfoque metódico con un análisis rápido y grosero (mpstat/top/atop), perfilado dirigido (perf) y trazado puntual (eBPF) proporciona hipótesis fiables. Medir, cambiar, revertir: ese es el orden. En Kubernetes es especialmente importante distinguir entre el pod y el nodo causante; una medida incorrecta puede afectar a todo el clúster.

Este runbook proporciona las herramientas y rutas de verificación para que administradores, system engineers y operadores analicen con fundamento, prueben de forma segura y reviertan cambios con responsabilidad.

Alta carga de CPU por hilos del kernel e irq/softirq — Medidas operativas y de arquitectura

Además del análisis inmediato, las medidas operativas y arquitectónicas sostenibles son decisivas para que el problema no vuelva a ocurrir. No tome decisiones basándose únicamente en un único perfil: desarrolle rutas permanentes de detección, prueba y Rollback que encajen en los procesos de cambio y en la automatización.

Detección continua y alertas

Una instantánea de perf a corto plazo solo sirve una vez. Configure alertas que detecten cambios en SoftIRQ por CPU y aumentos de PPS, y que avisen ante regresiones en componentes del kernel o CNI. Ejemplo de una Prometheus‑Rule sencilla:

- 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: calibre las reglas respecto a sus líneas base para evitar falsos positivos durante cargas estacionales.

Canary‑Änderungen und Rollout‑Strategie

Los cambios en sysctl, IRQ‑pinning u offloads deberían probarse en modo canary en unos pocos nodos. Flujo práctico:

• Cordon/drain de un nodo de prueba.
• Cambio mediante un sysctl‑drop‑in versionado.
• Mediciones automatizadas (5–15 minutos) frente a la línea base.
• Rollback en caso de empeoramiento.

Beispiel 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

Automatización e integración en Runbook

Integre scripts de comprobación en su automatización (Ansible, Salt, Terraform para instancias en la nube) y versione las configuraciones de sysctl/irqbalance en Git. Un trigger del runbook debería, tras actualizaciones del kernel, ejecutar un perfilado corto y escribir un informe de estado en su flujo de tickets. Así evitará sorpresas tras los parches.

Medidas arquitectónicas: desplazar carga, no solo parchear

Algunos problemas de SoftIRQ no se solucionan con tuning; aquí los pasos arquitectónicos son más efectivos:

• Reduzca los PPS a nivel de nodo mediante balanceadores L4/L7 en lugar de SNAT/NodePort para evitar presión de conntrack.
• El batching y el keep‑alive en software empresarial a medida reducen el número de paquetes; revise opciones de socket (TCP_CORK, sendmmsg) bajo cargas de PPS altas.
• Alinee las estrategias de offloading con el proveedor de la nube o del NIC: el HW‑offload puede desplazar la carga, pero también revelar incompatibilidades de drivers.

Riesgos, coordinación con el proveedor y artefactos de auditoría

Recoja hallazgos de forma estandarizada (perf raw, flamegraphs, instantáneas de atop, tcpdump‑pcap con marcas de tiempo) antes de abrir tickets con el proveedor. Sin artefactos reproducibles, el diagnóstico se alarga. Para cuestiones de kernel/driver, planifique rollouts escalonados de kernel y mantenga las entradas de arranque (GRUB) para una reversión rápida.

En resumen: apueste por higiene de monitorización, configuraciones versionadas, rollouts canary y revisión arquitectónica. Así la respuesta a altas cargas del kernel o de irq/softirq será predecible, medible y reversible — en consonancia con los procesos de cambio y de seguridad existentes para sus soluciones empresariales digitales.

Para este tema son también importantes el análisis con Atop y el perfilado de CPU con perf. El artículo sitúa estos aspectos de forma comprensible y muestra qué importa en la práctica diaria.