Ir al contenido 
Muestro cómo Métricas del servidor como el tiempo de inactividad de la CPU, la carga y el iowait, de forma que pueda separar los cuellos de botella reales de los picos inofensivos y tomar contramedidas específicas. Explico qué valores límite tienen sentido, cómo interactúan los ratios y cómo deduzco medidas concretas a partir de los valores medidos.
Puntos centrales
- CPU inactivamuestra el tiempo de cálculo libre y las fases de espera ocultas
- Promedio de cargamide las colas y la utilización del núcleo
- iowait: expone los frenos de almacenamiento y de red
- InteracciónReconocer patrones en lugar de ver los valores individuales de forma aislada.
- AlertasDefinir umbrales y tendencias significativos
Interpretar correctamente la inactividad de la CPU
Leo CPU inactiva como la proporción de tiempo en la que la CPU no está ejecutando nada ni esperando E/S, y siempre lo evalúo en el contexto de las cargas de trabajo actuales. Si Idle se mantiene con frecuencia por encima del 60-80 por ciento, planifico más tareas o reduzco los servicios porque hay reservas sin utilizar. Si la inactividad desciende por debajo del 20 por ciento durante un periodo prolongado, lo primero que busco son procesos atados a la CPU, bucles ineficientes y falta de paralelización. Si el ralentí cae mientras el tiempo de usuario (us) y el tiempo de sistema (sy) son altos, hay mucho que decir sobre el hambre computacional pura; si el ralentí cae mientras el iowait aumenta, por otro lado, esto indica bloqueos fuera de la CPU. Para los servidores web, considero saludable una media diaria de entre el 20% y el 40% de inactividad, siempre y cuando los tiempos de respuesta se mantengan estables y los usuarios no se vean notablemente afectados por ningún valor atípico.
Comprender la carga del servidor
Evalúo la Promedio de carga como el número medio de procesos que quieren calcular o están esperando tiempo de CPU, y compararlo directamente con el número de núcleos. Si la carga de 1 minuto supera repetidamente el número de núcleos, se crean colas, lo que se refleja en retrasos en la programación y en peticiones que tardan más en ejecutarse. Para las decisiones cotidianas, presto especial atención a la carga de 5 y 15 minutos porque suaviza los picos y evita falsas alarmas causadas por picos cortos. En un servidor de 4 núcleos, interpreto los valores de carga de hasta alrededor de 3,2 como una utilización sólida; para valores superiores a 4,0, examino activamente los procesos, bloqueos y rutas de E/S. Si quieres evitar las típicas interpretaciones erróneas de la carga, puedes encontrar consejos prácticos en Interpretación correcta del promedio de carga, donde hago tangibles los casos límite y los ejemplos de cálculo.
Delimitar claramente la espera de E/S (espera de CPU)
Diferencio entre iowait estrictamente de la utilización real, porque la CPU está lista, pero no puede calcular porque está esperando operaciones de memoria o de red. Si iowait se mantiene permanentemente por encima del 10%, compruebo primero las latencias de los soportes de datos, la profundidad de las colas, los cuellos de botella del sistema de archivos y las rutas de red. Si aparecen muchos procesos con estado D (suspensión ininterrumpida) en la parte superior, esto solidifica mi sospecha de que se están bloqueando los accesos de E/S. En tales casos, las unidades SSD NVMe, más IOPS, opciones de montaje optimizadas o una caché de páginas más grande aceleran el procesamiento antes de que piense en escalar. La guía ofrece una introducción compacta con imágenes de ejemplo típicas Entender la espera de E/S, para ayudarme con el diagnóstico inicial.
Clasificar correctamente la presión de la memoria
Separo Impresión en memoria consciente de los cuellos de botella de CPU y E/S, porque la escasez de memoria tiene sus propias firmas. Si la actividad de recuperación de páginas aumenta, veo las columnas si/so (swap in/out) en vmstat o las tasas de fallos de página en sar, y lo correlaciono con iowait y los tiempos de respuesta. La utilización moderada de swap no es automáticamente mala con una caché de páginas grande, pero el swap persistente ralentiza cualquier CPU. En tales situaciones, la proporción ociosa no disminuye necesariamente, mientras que la carga puede aumentar - los procesos entonces esperan por páginas recuperadas y bloquean la cola de ejecución. Yo compruebo específicamente la proporción de la caché de páginas (libre/buffers/caché), los fallos principales de los procesos afectados y la configuración de swappiness antes de escalar la RAM o ajustar las cachés. En Linux, también utilizo PSI (Pressure Stall Information) en /proc/pressure/memory para ver si las tareas están esperando notablemente por memoria. Si PSI muestra un aumento de las paradas en ventanas de tiempo significativas, aumento el alcance de la caché de páginas, alivio la carga con cachés de objetos/consultas en la aplicación o muevo los trabajos por lotes a ventanas más tranquilas para que las cargas de trabajo interactivas no se ahoguen debido a la presión de la memoria.
Interacción de ralentí, carga y espera
Califico el Interacción de los ratios, porque los patrones revelan más que los valores individuales. Una alta carga combinada con un alto ralentí suele indicar bloqueos de E/S: Muchos procesos están esperando, la propia CPU está aburrida. Un idle bajo con una carga baja, por otro lado, indica procesos individuales intensivos en computación que ocupan la CPU durante mucho tiempo sin causar grandes colas. Si el tiempo de robo (st) en las máquinas virtuales también aumenta, informo al hoster de un posible overbooking o me planteo cambiar de host. Sólo cuando la interacción funciona correctamente decido medidas como el escalado vertical, la distribución horizontal o la optimización selectiva del código.
Ten en cuenta la frecuencia de la CPU, el turbo y el estrangulamiento
Compruebo Frecuencias de CPU y Turbo Boost, porque los valores porcentuales (us/sy) pueden ser engañosos si la velocidad de reloj se escala dinámicamente. Si la frecuencia cae (ahorro de energía, estrangulamiento térmico), la potencia de cálculo absoluta cae, aunque en ralentí y carga puede parecer sin cambios. Leo los MHz actuales por núcleo (por ejemplo, a través de turbostat o cpupower) paralelamente a la utilización y evalúo los picos con vistas a la temperatura y el regulador (powersave, rendimiento). Si hay picos de latencia durante las fases cortas de inactividad, los estados C bajos (C6+) pueden aumentar el tiempo de activación - para los servicios de latencia crítica, establezco límites de estado C más conservadores o el gobernador de rendimiento, mientras que la carga por lotes se beneficia del ahorro de energía. Descubro Estrangulamiento térmico bajo carga continua, planifico mejoras de refrigeración, reduzco los trabajos en segundo plano no críticos en las fases calientes o distribuyo las cargas de trabajo para que los núcleos no se estrangulen y las métricas ofrezcan una imagen más realista.
NUMA, interrupciones y afinidad
Presto atención a Zonas NUMA y la distribución de interrupciones, porque el tráfico cruzado distorsiona las métricas. Si un subproceso accede repetidamente a la memoria en el nodo NUMA „equivocado“, las latencias aumentan notablemente, mientras que load e iowait muestran patrones como „mucho trabajo, pero poco progreso“. Compruebo los puntos calientes con numactl/numastat, asigno las cargas de trabajo a los nodos (CPU y memoria) según sea necesario y presto atención a los tamaños de buffer pool por socket para las bases de datos. Distribuyo la carga de red mediante RSS/RPS/XPS y compruebo /proc/interrupts para que un solo núcleo no cargue con todas las interrupciones NIC y actúe como cuello de botella. Si detecto acciones sy% elevadas con poco trabajo del usuario, lo interpreto como un indicador de impresión de IRQ, rutas de copia del kernel o checksumming - en estos casos, ayudan los controladores actualizados, las opciones de descarga personalizadas y un equilibrio justo de IRQ entre los núcleos.
Flujo de trabajo de diagnóstico rápido en el terminal
Empiezo con top o htop para ver inmediatamente el desglose de CPU (us, sy, ni, id, wa, hi, si, st), los valores de carga y los procesos conspicuos. A continuación, compruebo el tiempo de actividad para la carga de tres valores y comparo las tendencias de 1, 5 y 15 minutos con la hora del evento. Con vmstat obtengo una vista de flujo de la cola de ejecución, los cambios de contexto, la actividad de swap y los historiales de iowait. Para el soporte de datos, utilizo iostat, leo tps, await, svctm e identifico picos de latencia por dispositivo o LUN. Si pidstat y perf muestran puntos calientes en el código, doy prioridad a las rutas afectadas antes de pensar en el hardware, porque a menudo consigo ganancias rápidas con una pequeña corrección en el lugar adecuado.
Contenedores y Cgroups: reconocer el estrangulamiento
Tasa I Límites de los contenedores como posible causa si las imágenes de carga no coinciden. Si las cuotas de CPU (CFS) recortan el tiempo de proceso, veo un aumento de la carga con un tiempo us% sorprendentemente bajo porque las tareas están esperando la siguiente ventana de intervalo de tiempo. En Kubernetes, me aseguro de que solicita y límites sean realistas: Límites demasiado ajustados conducen a throttling, peticiones demasiado bajas conducen a cuellos de botella de programación en el nodo. Compruebo los contadores de estrangulamiento del cgroup, observo los contenedores con una alta tasa de cambio de contexto y cierro la afinidad de anclaje de la CPU y primero escalo las cuotas antes de actualizar los nodos. Los límites de memoria sin margen pueden llevar a muertes OOM - puedo reconocerlo por la terminación abrupta de procesos, fallos mayores conspicuos por adelantado y picos de latencia erráticos. Las contramedidas son límites de memoria razonables, distribución horizontal y búferes para tareas en segundo plano, de modo que las rutas productivas no se vean ralentizadas por los límites.
Seleccione los valores límite y las alertas con sensatez
He puesto Valores umbral para que informen de los riesgos reales y los picos a corto plazo no disparen constantemente las alarmas. Para la CPU en reposo, planifico avisos a partir de alrededor del 20%, para el iowait a partir del 10% y para la carga a partir del 80% de los núcleos, en cada caso con un breve retardo. Una segunda etapa con un umbral más alto activa la escalada o el autoescalado para darme tiempo a actuar. Para controlar las tendencias, utilizo la carga de 15 minutos y la comparo con patrones diarios y semanales para reconocer los picos estacionales. Envío las alertas en un paquete para mantenerme centrado en las situaciones de incidente y no perderme en las notificaciones.
| Métricas | Orientación | Advertencia | Crítica | Posible causa | Acción rápida |
|---|---|---|---|---|---|
| CPU inactiva | > 60 % | < 20 % | < 10 % | Ruta de código fuerte, muy pocos núcleos | Perfilar y paralelizar los puntos conflictivos |
| Carga | < Número de núcleos | > 0,8 × núcleos | > 1,0 × núcleos | Colas, bloqueos, congestión de E/S | Comprobar los procesos principales, reducir el bloqueo |
| iowait | < 5 % | > 10 % | > 20 % | Disco/red lentos, tacos demasiado pequeños | NVMe/RAID, aumentar la profundidad de la cola |
Planificación de capacidades con SLO y líneas de base
Enlaces Capacidad con SLO (por ejemplo, tiempo de respuesta 95%) en lugar de limitarse a los valores medios. Para la CPU, establezco objetivos de margen (por ejemplo, P95 de inactividad no inferior al 20%) para que los picos de carga cortos no se conviertan inmediatamente en colas. Para la carga, utilizo líneas de base históricas por hora del día y temporada para construir umbrales dinámicos que tengan en cuenta el crecimiento o las campañas. Defino las alertas como un compuesto: Solo cuando, por ejemplo, Carga > núcleos, iowait > 10% y aumenta la latencia P95, se dispara la etapa 2. En entornos de nube, planifico las reservas de etapa (por ejemplo, +25 por ciento de núcleos, +x IOPS) y tengo listos playbooks sobre cómo las reglas de autoescalado surten efecto sin generar un thrash. Pruebo los cambios con mediciones A/B, documento las métricas antes/después y me aseguro de que las optimizaciones no solo desplacen la carga, sino que eliminen los cuellos de botella a largo plazo.
Causas típicas y soluciones
A menudo veo valores de iowait altos para volúmenes de nube pequeños con garantías de IOPS insuficientes, por lo que cambio específicamente a almacenamiento NVMe o volúmenes más grandes con mayores garantías y reduzco significativamente los tiempos de espera. Si se produce una carga elevada con iowait normal, suelo encontrar regex ineficientes, cachés ausentes u ORM parlanchines, que mitigo con índices, ajuste de consultas y caché de respuesta. Si domina el tiempo del sistema, me fijo en las interrupciones de red, los estados de los controladores y las funciones de descarga de la NIC, porque las tormentas de IRQ inmovilizan la CPU. En caso de caídas esporádicas con tiempo de robo simultáneo en las máquinas virtuales, compruebo la ocupación del host y muevo una ventana de reubicación a un vecindario más tranquilo. Si la aplicación escala horizontalmente, sello los cuellos de botella con cachés centrales, colas asíncronas y tiempos de espera claros para que los valores atípicos individuales no bloqueen todo el nodo.
Virtualización: anote el tiempo de robo
Mido robar tiempo (st) en entornos virtualizados porque muestra cuánto tiempo de computación está desviando el hipervisor. Si st aumenta regularmente por encima de unos pocos puntos porcentuales, envío el ticket al proveedor con documentos de métricas y solicito la reubicación o recursos dedicados. En los escenarios multiinquilino, también planifico buffers para la carga, de modo que los cuellos de botella breves causados por los vecinos no provoquen directamente alarmas. En el lado del host, estrangulo los trabajos en segundo plano innecesarios para crear más espacio para la carga productiva en ventanas sensibles. Para los sistemas críticos, prefiero núcleos dedicados o instancias bare-metal para garantizar latencias predecibles.
Cuadros de mando y prácticas de supervisión
Construyo Cuadros de mando para que muestren juntos los valores de avería de CPU, carga, iowait, memoria, disco y red y me proporcionen cadenas de causas en segundos. Los intervalos de muestreo cortos de cinco segundos revelan los picos, mientras que las vistas resumidas hacen visibles las tendencias. Formo alertas en función de la estacionalidad y la hora del día para que los turnos de noche no se activen en cada pico. Los playbooks, en los que almaceno pruebas estándar y rutas de escalado, me ayudan con el análisis para que nadie empiece de cero. Si quieres empezar de forma estructurada, puedes echar un vistazo a mi artículo Análisis de los datos de seguimiento que resume los paneles y las figuras clave más importantes.
Pruebas de rendimiento sin ángulos muertos
Compruebo Cuellos de botella no sólo a plena carga, sino también en fases de inactividad, porque las copias de seguridad, los trabajos cron y las ejecuciones de índices suelen interferir por la noche. Para las aplicaciones con tráfico en ráfagas, creo perfiles de carga realistas que incluyen cachés frías y fases de calentamiento. Registro sistemáticamente comparaciones A/B antes y después de los cambios para poder separar los efectos reales de las fluctuaciones aleatorias. En el caso de las rutas de memoria, correlaciono la latencia, la profundidad de las colas y el rendimiento para reconocer la causa y el efecto. A nivel de red, utilizo la captura de paquetes de forma selectiva si las métricas por sí solas no explican por qué se atascan las peticiones.
Recetas prácticas: Muestras para medidas
- Carga alta, inactividad alta, iowait alto: compruebe las rutas de E/S, aumente la profundidad de la cola, almacene en caché antes del disco.
- Baja carga en vacío: Un único hilo caliente: perfilado, paralelización o procesamiento por lotes.
- Alto sy%, normal us%: Optimizar IRQ/kernel hotpath, driver/offloading y distribución de interrupciones.
- Carga cercana al recuento de núcleos, los picos de latencia sólo se producen bajo aceleración turbo: compruebe la refrigeración/el regulador, evite la aceleración.
- Contenedores con carriles de estrangulamiento: aumentar las cuotas de CPU, armonizar las peticiones/límites, reducir el co-arrendamiento.
- Memoria-PSI aumentada, iowait moderada: ajustar caché de páginas/conjunto de trabajo, añadir RAM o mover trabajos por lotes.
Brevemente resumido
Leo CPU inactiva, Load e iowait siempre trabajan juntos porque el patrón proporciona los hallazgos y aclara mis próximos pasos. Con umbrales claros, intervalos cortos y cuadros de mando significativos, evito los vuelos a ciegas y reacciono a tiempo. Busco puntos calientes en el código para la carga de la CPU, mejores rutas de E/S y almacenamiento en caché para iowait, y racionalizo las colas y la sincronización para cargas elevadas. En las máquinas virtuales, incluyo el tiempo de robo para que los límites de la infraestructura no aparezcan como un problema de la aplicación. Mantener esta disciplina reduce los fallos, utiliza los recursos con sensatez y mantiene los tiempos de respuesta bajos y fiables.
