Entrevista de Linux: ¿Cómo explicar y diagnosticar la latencia de programación de la CPU?

Prompt y roles aplicables

Un servidor de 16 vCPU que ejecuta Linux 6.12 y cgroup v2 aloja una API sensible a la latencia junto con un trabajo de compresión fuera de línea. Después de que se inicia el trabajo fuera de línea, el p99 de la API sube de 45 ms a 600 ms. La monitorización del host reporta aproximadamente un 78% de utilización agregada de CPU, y la API acumula poco tiempo de CPU. Todos los subprocesos relevantes de la API y del trabajo fuera de línea utilizan SCHED_OTHER.

Explique cómo el programador justo moderno de Linux selecciona entre los subprocesos ejecutables y, a continuación, proporcione un proceso de diagnóstico comprobable que distinga estas causas:

• los subprocesos de la API están listos para ejecutarse (runnable) pero esperan demasiado por una CPU;
• el cgroup de la API está limitado por su cuota cpu.max;
• la afinidad o un cpuset confina el trabajo a unas pocas CPU ocupadas;
• los subprocesos de la API en realidad están suspendidos esperando un mutex, E/S u otro evento;
• subprocesos de tiempo real de mayor prioridad impiden que los subprocesos normales se ejecuten.

Esta pregunta es adecuada para roles de SRE, infraestructura, software de sistemas, ingeniería de rendimiento y backend que requieren conocimientos del entorno de ejecución de Linux. Los valores 16, 6.12, 45 ms, 600 ms y 78% son datos ficticios de ejercicio, no umbrales universales de capacidad o alerta.

Qué está evaluando el entrevistador

El primer límite es el estado de la tarea. Un programador solo puede seleccionar subprocesos ejecutables (runnable). Un subproceso suspendido esperando un mutex, una operación de red, una operación de disco o un temporizador no está esperando en una cola de ejecución de CPU. Todo ese intervalo no debe etiquetarse como retraso de programación. El candidato debe responder primero si el subproceso ya estaba en estado ejecutable.

La segunda capa es el modelo de programación justa. La explicación histórica de CFS utiliza el tiempo de ejecución virtual, o vruntime, para aproximar una "CPU multitarea ideal" y favorece a las entidades con un vruntime menor. El modelo actual EEVDF continúa rastreando la deuda de equidad llamada lag, admite solo entidades elegibles y selecciona el plazo virtual más temprano (earliest virtual deadline) entre ellas. Un valor nice o una ponderación de cgroup afecta la proporción relativa a largo plazo. Una porción de solicitud (request slice) y un plazo virtual afectan qué tan pronto una tarea puede obtener otra oportunidad de ejecución. Ninguno de los mecanismos promete un p99 fijo para una solicitud individual.

La tercera capa es la jerarquía y las restricciones locales. Un host con un 22% de capacidad inactiva aún puede tener un cgroup de destino que agotó una cuota estricta o un subproceso confinado a dos CPU saturadas. cpu.weight es una ponderación relativa entre cgroups hermanos activos durante la contención, mientras que cpu.max impone un límite estricto de ancho de banda por período. Los grupos de tareas y los cpusets pueden hacer que un valor agregado del host oculte la inanición local.

La cuarta capa es la evidencia directa. La espera en la cola de ejecución de /proc/12345/schedstat, el retraso de ejecutable a ejecución de perf sched timehist, y cpu.stat y cpu.pressure de cgroup están más cerca del mecanismo que la CPU agregada o un recuento de cambios de contexto por sí solos. Una respuesta sólida también delimita el privilegio de rastreo, la sobrecarga y la duración.

Finalmente, el candidato necesita un límite de mitigación. Mover la API a SCHED_FIFO puede hacer que se apropie del trabajo normal, pero un bucle no acotado o el titular de un bloqueo podrían entonces provocar la inanición de la máquina. La solución debe seguir la evidencia: corregir una cuota incorrecta, ajustar las ponderaciones entre hermanos, reparar un conjunto de CPU o investigar una ruta de bloqueo o de E/S cuando el subproceso no estaba ejecutable.

Preguntas para aclarar antes de responder

• ¿Dónde comienza y termina la medición del p99? Separe el encolamiento de entrada, la ejecución de la aplicación, la espera downstream y el tiempo de red del cliente, y alinee las muestras del host con el mismo intervalo.
• ¿Cuándo está ejecutable el subproceso objetivo? Obtenga estados de los subprocesos, razones de salida de CPU (off-CPU) o trazas de pila (stacks). Poco tiempo de CPU puede significar falta de programación o suspensión prolongada.
• ¿Qué jerarquía de cgroups contiene la API y el trabajo fuera de línea? Compare cpu.weight, cpu.max, los límites principales y cpu.stat para ambos. Un cgroup padre también restringe a sus hijos.
• ¿Qué CPU pueden ejecutar el trabajo? Verifique la afinidad de los subprocesos, cpuset.cpus.effective, la utilización por CPU y la topología NUMA. Un host de 16 vCPU no significa que el subproceso tenga permitido usar las 16.
• ¿Hay entidades de programación en tiempo real? Inspeccione las prioridades y la afinidad de CPU para el trabajo SCHED_FIFO y SCHED_RR. El enunciado solo dice que los subprocesos comerciales relevantes usan SCHED_OTHER; no excluye subprocesos de tiempo real no relacionados en el host.
• ¿El trabajo fuera de línea alteró una ruta de bloqueo, memoria o E/S? La compresión puede generar contención de CPU, pero también puede intensificar la recuperación de memoria, la E/S de archivos o el encolamiento en un grupo de trabajadores compartido.
• ¿Se puede capturar una traza corta? perf sched suele requerir privilegios adicionales y genera sobrecarga de grabación. Confirme la dirección primero con contadores de baja sobrecarga y luego tome muestras durante 15 segundos en una ventana controlada.

Estructura de respuesta de 30 segundos

"Primero establecería si el subproceso de la API ya estaba en estado ejecutable durante una solicitud lenta. El tiempo suspendido en un bloqueo o E/S es una espera fuera de CPU. El retraso de programación es el intervalo desde que está ejecutable hasta que realmente se ejecuta.

En Linux 6.12, explicaría la clase fair a través de EEVDF: rastrea el desfase (lag) de cada entidad con respecto al servicio justo ideal, considera las entidades elegibles y selecciona el plazo virtual más temprano. El modelo de menor vruntime de CFS sigue siendo una intuición histórica útil, pero no describe completamente la regla de selección actual. Nice y cpu.weight cambian la proporción relativa, cpu.max puede limitar directamente, y la afinidad o un cpuset controla qué CPU están disponibles.

Inspeccionaría la utilización por CPU, los estados de los subprocesos y la configuración de cgroup. Luego compararía el delta de espera en la cola de ejecución en /proc/12345/schedstat, los deltas de limitación en cpu.stat y cpu.pressure. Si la evidencia aún apunta a la programación, capturaría una traza corta con perf sched para medir directamente el retraso de ejecutable a ejecución. Después de aplicar una corrección, reproduciría la misma carga y verificaría el p99 de la API, la distribución del retraso de programación, la limitación, la presión de CPU y el rendimiento (throughput) fuera de línea de manera conjunta, en lugar de deducir una causa a partir del 78% de CPU agregada."

Análisis detallado paso a paso

Paso 1: Trazar la línea entre ejecutable y suspendido

Cuando una CPU necesita otra tarea, el programador de Linux elige únicamente una entidad ejecutable en esa CPU o elegible para migrar allí. Los subprocesos de política normal tienen prioridad de programación 0. Los subprocesos de tiempo real SCHED_FIFO y SCHED_RR utilizan un rango de prioridad estática más alto y pueden apropiarse de los subprocesos normales.

Por lo tanto, el bajo tiempo de CPU de la API tiene dos explicaciones fundamentalmente diferentes:

1. El subproceso está ejecutable pero no se ejecuta oportunamente debido a contención en la cola de ejecución, una cuota o restricciones del conjunto de CPU.
2. El subproceso está suspendido en un futex, socket, disco, temporizador o cola de la aplicación y pasa a ejecutable solo cuando llega el evento.

Comience inspeccionando el estado del subproceso y la política de programación:

ps -eLo state,cls,rtprio,pri,ni,psr,pid,tid,comm --sort=-rtprio,-pri
pidstat -t -w -u -p "$pid" 1 10

ps es una captura instantánea, por lo que un solo R o S no resuelve la cuestión. Los datos de cambios de contexto y de CPU de pidstat ayudan a identificar los subprocesos objetivo, pero un recuento alto de cambios de contexto no demuestra un retraso de programación elevado. Si el subproceso duerme la mayor parte del tiempo, continúe con un rastreo de la aplicación, perfilado de bloqueos, pilas off-CPU, métricas de E/S y latencia downstream para localizar la condición de activación.

Paso 2: Usar CFS como intuición y luego actualizar el modelo a EEVDF

La explicación clásica de CFS escala el tiempo de ejecución real de cada entidad justa por su ponderación para obtener vruntime. Una entidad con más ponderación acumula vruntime más lentamente. Seleccionar una entidad con menor vruntime orienta el servicio a largo plazo hacia las ponderaciones configuradas. Eso sigue siendo una intuición didáctica útil y explica la dirección en la que nice modifica la proporción equitativa.

La documentación del kernel de Linux indica que la clase fair comenzó la transición a EEVDF en la versión 6.6. Una respuesta concisa puede basarse en dos conceptos:

• lag representa cuánto servicio se le debe a una entidad o cuánto ha recibido en relación con el servicio justo ideal; una entidad con lag >= 0 es elegible;
• entre las entidades elegibles, el programador elige el plazo virtual más temprano. Una porción solicitada más corta produce un plazo más temprano y mejora la oportunidad de respuesta para el trabajo sensible a la latencia.

EEVDF gestiona el equilibrio entre equidad y latencia, pero de una ponderación de carga no se deduce un SLA fijo en milisegundos. La espera real sigue dependiendo de las CPU disponibles, el recuento de entidades, la jerarquía de ponderaciones, las cuotas, el momento de activación y las clases de programación superiores. En una entrevista, utilice vruntime de CFS para la intuición histórica y luego concluya con la regla de selección de EEVDF requerida por la pregunta de Linux 6.12.

Paso 3: Separar nice, ponderación relativa, cuota estricta y conjunto de CPU

Para SCHED_OTHER, el rango normal de nice es de -20 a 19, y Linux mantiene valores de nice por subproceso. Nice altera la ponderación relativa dentro de la clase fair. No reserva CPU y no puede eliminar un límite de cgroup. Con la programación por grupos de tareas, las entidades en diferentes cgroups primero compiten a nivel de grupo. Cambiar el nice de un subproceso dentro de un grupo puede tener poco impacto en la proporción entre dos cgroups.

Tres controles de cgroup v2 responden a diferentes interrogantes:

• cpu.weight tiene un valor predeterminado de 100 y va de 1 a 10000; distribuye los ciclos de CPU disputados proporcionalmente entre los hermanos activos;
• cpu.max tiene el formato $MAX $PERIOD y su valor predeterminado es max 100000; un máximo numérico limita todo el cgroup una vez agotado el presupuesto del período;
• cpuset.cpus.effective es el conjunto de CPU realmente disponible tras aplicar la jerarquía y el estado del sistema.

Lea las restricciones del host, del subproceso y del cgroup de destino:

mpstat -P ALL 1 10
taskset -pc "$pid"
cat /sys/fs/cgroup/api/cpuset.cpus.effective
cat /sys/fs/cgroup/api/cpu.weight
cat /sys/fs/cgroup/api/cpu.max
cat /sys/fs/cgroup/api/cpu.stat
cat /sys/fs/cgroup/api/cpu.pressure

Si nr_throttled y throttled_usec en cpu.stat aumentan durante el intervalo de solicitudes lentas, el cgroup efectivamente alcanzó su límite de ancho de banda. Un presupuesto estricto de grupo puede detener ese grupo incluso mientras otras CPU del host están inactivas; ambas métricas tienen alcances diferentes. Si los contadores de cuota permanecen planos pero cpuset.cpus.effective es solo 2-3 y las CPU 2 y 3 están saturadas, el promedio del 78% del host resulta igualmente engañoso.

Paso 4: Medir directamente la espera desde ejecutable hasta en ejecución

Tras elegir un subproceso lento representativo, lea sus contadores de programación dos veces:

cat /proc/"$tid"/schedstat
sleep 5
cat /proc/"$tid"/schedstat

Los tres campos son los nanosegundos acumulados ejecutándose en una CPU, los nanosegundos acumulados esperando en una cola de ejecución y el número de porciones de tiempo (timeslices) obtenidas. Utilice el delta entre lecturas en lugar del total acumulado. Un crecimiento rápido en el segundo campo con poco tiempo de ejecución respalda la hipótesis de "ejecutable pero no ejecutándose oportunamente", aunque aún se necesita cuota, afinidad y subprocesos de mayor prioridad para explicar el porqué.

Cuando se requiera una distribución y una línea de tiempo, tome una breve traza a nivel de todo el sistema:

sudo perf sched record -a -- sleep 15
sudo perf sched timehist --state --summary

perf sched timehist puede mostrar el tiempo de espera, el retraso de programación de ejecutable a ejecución y el tiempo de ejecución, al tiempo que sitúa las reactivaciones, migraciones y CPU en una línea temporal. En producción, confirme primero el soporte del kernel, los privilegios, el espacio en disco y la sobrecarga aceptable. Limite la ventana de recolección y elimine los datos de rastreo que ya no sean necesarios. Una sola muestra de 15 segundos que pase por alto un evento de cola no exonera al programador; compare distribuciones a través de ejecuciones reproducibles de antes y después.

Paso 5: Converger en cinco causas con evidencia discriminante

Utilice la siguiente matriz para acotar la causa:

cpu.pressure mide el tiempo durante el cual el trabajo ejecutable no puede avanzar debido a la contención de CPU. Es una evidencia útil de que la competencia por la CPU afecta la carga de trabajo, pero no distingue una ponderación relativa insuficiente de la limitación por cuota o un anclaje deficiente. cpu.stat, la afinidad y las trazas del programador completan esa distinción.

El trabajo en tiempo real sigue una ruta de prioridades independiente. Un subproceso SCHED_FIFO se ejecuta hasta que se bloquea, es desalojado por un subproceso de tiempo real de mayor prioridad o cede el control. SCHED_RR añade un cuanto solo entre subprocesos con la misma prioridad de tiempo real. Ninguna ponderación de la clase fair permite que un subproceso normal supere a un subproceso de tiempo real de mayor prioridad continuamente ejecutable.

Paso 6: Corregir el mecanismo comprobado y verificar tanto las métricas de negocio como las del programador

Cada mitigación debe corresponder a un mecanismo confirmado:

• cuota incorrecta: aumente o elimine el cpu.max incorrecto tras evaluar la capacidad y el impacto en vecinos;
• cuota relativa insuficiente: aumente la ponderación del cgroup de la API, reduzca la ponderación del cgroup fuera de línea o baje la prioridad nice de la tarea fuera de línea;
• conjunto de CPU deficiente: amplíe o reequilibre el cpuset o la afinidad comprobando la localidad NUMA y de caché;
• contención de la clase fair: limite la concurrencia fuera de línea, divida los lotes o utilice SCHED_BATCH o SCHED_IDLE para el trabajo fuera de línea que corresponda;
• espera por suspensión: corrija la contención de bloqueos, los grupos de trabajadores, la E/S, la presión de memoria o un servicio downstream; el ajuste del programador generalmente no aporta beneficios;
• inanición por tiempo real: elimine una política de tiempo real innecesaria, delimite el tiempo de ejecución e inspeccione la inversión de prioridades y las dependencias de bloqueo.

Ejecute una comparación de antes y después con la misma tasa de solicitudes y carga fuera de línea. Verifique al menos el p50/p95/p99 y errores de la API, la distribución del retraso de programación por subproceso, los deltas de espera en cola de ejecución de schedstat, la limitación de cgroup, la presión de CPU, la utilización por CPU y el rendimiento fuera de línea. Mejorar el p99 de la API no debe privar permanentemente de recursos al trabajo fuera de línea ni transferir presión a un servicio downstream o a otro inquilino.

Ejemplo de respuesta sólida

"Un promedio de CPU del 78% en el host no absuelve al programador. Linux programa subprocesos, y las restricciones pueden residir a nivel de subproceso, CPU o cgroup. Primero establecería si el subproceso que atiende una solicitud lenta está en estado ejecutable. Si está suspendido en un futex o E/S, su bajo tiempo de CPU refleja principalmente la espera de una señal de activación, por lo que el programador no pudo seleccionarlo.

El enunciado especifica Linux 6.12. vruntime de CFS explica la intuición de equidad, pero la selección actual debe describirse con EEVDF: el programador rastrea el lag respecto al servicio ideal, permite competir a las entidades con lag >= 0 y selecciona el plazo virtual más temprano. Nice y cpu.weight alteran la proporción relativa a largo plazo; cpu.max establece un tope periódico estricto; la afinidad y los cpusets restringen las CPU elegibles. Ninguno de estos mecanismos garantiza automáticamente un p99 de 45 ms.

Ejecutaría mpstat -P ALL y luego leería cpuset.cpus.effective, cpu.weight, cpu.max, cpu.stat y cpu.pressure para el cgroup de la API. Si nr_throttled y throttled_usec crecen durante todo el intervalo lento, se observa directamente limitación por cuota; la capacidad inactiva del host no altera esa conclusión. Si el trabajo está confinado a las CPU 2 y 3 y esas CPU están al 100%, repararía primero el conjunto local de CPU.

Sin anomalías de limitación ni de anclaje, tomaría dos lecturas de /proc/12345/schedstat para un TID representativo y calcularía el delta de espera en la cola de ejecución. Bajo una carga reproducible, capturaría brevemente perf sched record e inspeccionaría timehist para evaluar el retraso de ejecutable a ejecución, el activador (waker) y la CPU. Una baja espera en la cola de ejecución combinada con una suspensión prolongada redirigiría la investigación hacia bloqueos, E/S, colas de la aplicación y trazas downstream.

Supongamos que la evidencia muestra que el cgroup de la API está configurado como 20000 100000, con una limitación que aumenta a la par del p99. Corregiría el presupuesto utilizando la capacidad medida y limitaría la concurrencia fuera de línea. No movería simplemente la API a SCHED_FIFO. La nueva prueba utilizaría el mismo tráfico y el mismo trabajo por lotes, y exigiría que el p99 de la API, el retraso de programación, la limitación y la presión de CPU disminuyan juntos, manteniendo al mismo tiempo un rendimiento fuera de línea aceptable y sin provocar inanición en ninguna tarea."

Errores comunes

• Tratar el 78% de CPU del host como prueba de que no hay un problema de CPU → un promedio oculta las cuotas de cgroup y los conjuntos locales de CPU → inspeccione conjuntamente las vistas por CPU, de cgroup y de subprocesos.
• Llamar retraso de programación a todo el tiempo fuera de CPU → un subproceso suspendido aún no es ejecutable → utilice estados, pilas y trazas para establecer primero el punto de activación.
• Recitar únicamente "CFS elige el vruntime más pequeño" → la clase fair comenzó la transición a EEVDF en Linux 6.6 → explique el lag elegible y el plazo virtual más temprano.
• Asumir que cpu.weight=200 reserva dos CPU → el peso expresa la proporción relativa entre hermanos activos bajo contención → diseñe la capacidad por separado y use cpu.max para un límite estricto.
• Asumir que nice ordena directamente todos los contenedores → los grupos de tareas compiten primero en la jerarquía de cgroups → inspeccione las ponderaciones de grupo antes de decidir si cambia el nice del subproceso.
• Inferir latencia del programador a partir de muchos cambios de contexto → la E/S y la concurrencia normales también generan cambios → mida la espera en la cola de ejecución con schedstat y el retraso con perf sched.
• Usar SCHED_FIFO como una solución rápida para la API → un subproceso de tiempo real de alta prioridad puede causar inanición del trabajo normal y amplificar el riesgo de bloqueos → considere una política de tiempo real solo para plazos reales, tiempo de ejecución acotado y un análisis de seguridad completo.
• Aumentar la ponderación de la API sin verificar la cuota → el cgroup seguirá limitándose tras alcanzar cpu.max → demuestre la limitación con cpu.stat y corrija el límite.
• Verificar únicamente el p99 de la API → un cambio puede causar inanición del trabajo por lotes o degradar a otro inquilino → verifique también la equidad, el rendimiento, la presión y los errores.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Por qué un cgroup puede limitarse mientras el host todavía tiene CPU inactivas?

cpu.max limita el ancho de banda de CPU consumido por ese cgroup durante un período. Tras agotarse el presupuesto, el grupo espera al siguiente período, incluso si las CPU no utilizadas por otros grupos están inactivas. Inspeccione cpu.max y compare los deltas en nr_throttled y throttled_usec de cpu.stat durante el mismo intervalo. Esos valores responden si se activó el límite estricto de forma más directa que la utilización agregada del host.

Pregunta de seguimiento 2: ¿Por qué cambiar el nice del subproceso de la API podría tener poco efecto?

Linux aplica nice por subproceso, pero con la programación por grupos, los diferentes cgroups compiten primero como entidades de programación utilizando ponderaciones de grupo. Modificar el nice cambia principalmente la cuota de un subproceso dentro de su grupo. No puede eliminar un cpu.max padre y podría no alterar la relación entre los grupos de la API y fuera de línea. Mapee la jerarquía de cgroups y las ponderaciones antes de elegir el nice del subproceso o el cpu.weight del grupo.

Pregunta de seguimiento 3: ¿Mover la API a SCHED_FIFO solucionaría el p99?

Puede acortar la espera del subproceso objetivo, pero introduce un riesgo mayor. Un subproceso FIFO continuamente ejecutable puede suprimir todo el trabajo normal de la clase fair. Si realiza spin, mantiene un bloqueo o depende de un subproceso normal al que priva de CPU, el sistema puede dejar de avanzar. Evalúe una política de tiempo real solo cuando el trabajo tenga un plazo real, el tiempo de ejecución esté estrictamente acotado, la inversión de prioridades esté gestionada y exista protección de reserva.

Pregunta de seguimiento 4: ¿Garantiza EEVDF el servicio de CPU dentro de una porción (slice)?

No. Un plazo virtual ordena las entidades de programación elegibles y una porción expresa una preferencia de latencia. Las CPU disponibles, el número de entidades, las ponderaciones, las cuotas, la afinidad y las clases de programación superiores siguen afectando el tiempo de espera real. EEVDF suministra un mecanismo del programador para equilibrar equidad y latencia; no constituye un SLA de p99 comercial.

Pregunta de seguimiento 5: ¿Cómo se separa la espera de mutex de la espera en la cola de ejecución?

Un subproceso que espera un mutex normalmente se suspende y pasa a ser ejecutable tras liberarse el bloqueo. La espera en la cola de ejecución comienza una vez que es ejecutable. Alinee las pilas off-CPU de la aplicación o eBPF y las métricas de futex o de bloqueo con /proc/12345/schedstat y perf sched timehist. Una suspensión prolongada por futex con baja espera en la cola de ejecución apunta a un bloqueo; un retraso prolongado de ejecutable a ejecución apunta a la programación o al control de recursos.

Pregunta de seguimiento 6: ¿Cuándo puede ayudar realmente la asignación fija de CPU (CPU pinning)?

Un aislamiento bien diseñado puede reducir migraciones, disrupciones de caché y vecinos ruidosos, por ejemplo al reservar CPU con capacidad probada para subprocesos sensibles a la latencia. El conjunto de CPU debe ser lo suficientemente grande, las interrupciones y el trabajo en segundo plano requieren control, y las colas por CPU demandan monitorización. Una asignación fija deficiente genera congestión local mientras la capacidad del host permanece inactiva, por lo que se debe verificar el resultado con la utilización por CPU y el retraso de programación.