Núcleo saturado

En resumen: un núcleo saturado en el RB5009 de cuatro núcleos se lee como cerca de un 29 % del equipo, así que es la fila por núcleo, y no el total, la que muestra un cuello de botella de un solo hilo: aquí un núcleo al 99,8 % mientras los otros tres estaban ociosos. A 10 Hz se ve al planificador mover la carga entre núcleos durante unos 20 s antes de asentarse; muestreado una vez por segundo, eso es una meseta difusa. La carga se provocó a propósito.

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · Linux 5.6.3 · 2026-09-12 · agente a 10 Hz en un contenedor privilegiado efímero

Montaje

Un bucle de consola que quema un núcleo y termina por sí solo, sin ningún cambio de configuración y sin dependencias externas:

:local i 0; :while ($i < 4000000) do={ :set i ($i + 1) }

Duró 58,8 s.

Grabación

En tramos de 5 segundos. El agente envía deltas de ticks en bruto; los porcentajes de abajo se calcularon a partir de ellos después. No hay gráfico: la ejecución es anterior al historial del almacén InfluxDB de referencia, que empieza el 2026-09-19.

   t  busy%   per-core busy%          ctxt/s  temp   MHz
   0   22.3   31.8   7.4  40.4   9.6    9192  36.5  1400
   1   30.9   11.7  11.4  89.7  10.6   11325  37.0  1400
   2   29.9   14.3   9.4  19.6  76.0    9476  37.0  1400
   3   29.1    7.4   9.4  17.6  81.6   10805  37.0  1400
   4   29.3    3.1   9.4   4.9  99.8    9257  37.2  1400
   8   28.4    2.2   7.0   4.6  99.8   11947  37.2  1400
  11   33.0   11.8  11.2   9.0  99.7   12222  37.3  1400

Qué mirar

Un total de ~29 % es un núcleo de cuatro. El total del equipo es una trampa; mira siempre la fila por núcleo. “29 % de CPU” significa aquí “un núcleo está saturado y tres están ociosos”, lo que para un cuello de botella de un solo hilo es toda la historia.
El planificador tardó ~20 s en asentarse. Los tramos 0–3 muestran el trabajo moviéndose entre núcleos (40 % → 90 % → 76 % → 82 %) antes de fijarse en el núcleo 3 al 99,8 %. Si muestreas cada 1 s o más despacio ves una meseta difusa; a 10 Hz ves la migración.
La temperatura lo siguió: de 36,5 a 37,3 °C. Un núcleo saturado vale ~0,8 °C en esta placa con refrigeración pasiva. Poco, pero sigue la carga, y se lee de /sys/class/thermal sin ninguna llamada a la API.
La frecuencia se quedó plana en 1400 MHz. En este equipo eso es una configuración, no una observación: el propietario ha fijado el reloj al máximo, lo que /system/routerboard/settings indica como Warning: cpu not running at default frequency. En un equipo que escala, el campo freq_khz es donde verías un tick ocupado que se ganó despacio. El agente lee la frecuencia en cada tick y guarda freq_khz solo cuando cambia, más un latido cada 60 s, así que con un reloj fijo tienes una fila por minuto, y con un reloj que escala tienes cada escalón que dure al menos un tick.

Comprobar el muestreador

Antes de concluir nada de un número de CPU, confirma que mikroscope_slipped_total es 0. Un tick perdido es uno cuya lectura terminó después de que tocara el siguiente tick, y entonces la propia contabilidad del muestreador es lo primero de lo que deberías desconfiar.

Carga en el kernel

La forma contraria: los núcleos no están ocupados, pero el kernel sí. Llegó sola al RB5009 de referencia, con RouterOS 7.24.4, el 2026-09-23 a las 12:08:50 UTC, cuando una integración MikroTik de Home Assistant desató una tormenta de despertares:

Las interrupciones del temporizador pasaron de unas 2 500 a unas 35 000 por segundo, en ráfagas de 20–90 s en un núcleo cada vez, mientras el tiempo de usuario y el tráfico seguían planos.
Apenas se vio en el propio profile de RouterOS, y las columnas de ocupación de arriba no la habrían recogido. La tasa de cambios de contexto sí: en ese router se movió con las interrupciones del temporizador (r = 1,0).
Desactivar la integración el 2026-09-24 devolvió el temporizador a unas 2 500 por segundo en 30 s.

Es un solo evento en un solo router, leído del almacén InfluxDB de referencia, y aún no tiene caso propio. La regla que la vigila es mikroscope-wakeup-storm, en Reglas de alerta, que compara la tasa de cambios de contexto de los últimos diez minutos con las 24 horas anteriores del propio router.

Firma

Provocado a propósito · 2026-09-12

Un total del equipo cercano al 100 % dividido entre el número de núcleos — aquí ~29 % con cuatro núcleos — con una columna por núcleo al 99,7–99,8 %.
Antes de asentarse, la carga saltando visiblemente entre núcleos durante decenas de segundos.
Una subida de temperatura de menos de un grado que sigue a la carga.

Escrito y mantenido por José Manuel Requena Plens (jmrplens)jmrp.ioGitHub