Ir al contenido 
Promedio de carga muestra cuántos procesos se están ejecutando actualmente o están esperando tiempo de CPU, no el porcentaje de uso de la CPU. Quienes leen el valor sin contexto suelen reaccionar con pánico o realizan actualizaciones erróneas; explico cómo lo clasifico correctamente y cómo deduzco decisiones de alojamiento sensatas a partir de él.
Puntos centrales
- Sin CPU%: Load cuenta los procesos en la cola de ejecución.
- Por núcleo Pensar: dividir la carga por el número de núcleos.
- Espera de E/S A menudo consume más energía que la CPU.
- 1/5/15El promedio de minutos suaviza los picos.
- Contexto antes de las medidas: hora, trabajos, tráfico.
Lo que realmente mide el promedio de carga
Leo el valor como el número medio de Procesos, que se ejecutan activamente durante 1, 5 y 15 minutos o que esperan en la cola de ejecución. Muchos lo confunden con la carga de la CPU en porcentaje, pero el contador solo conoce las colas, no el tiempo de cálculo. Una carga de 1,0 significa una utilización completa permanente en un sistema de un solo núcleo, mientras que el mismo valor en cuatro núcleos sigue siendo relajado. Por lo tanto, siempre comparo la carga en relación con la cifra clave y solo entonces evalúa si existe una sobrecarga real. El promedio de 15 minutos muestra las tendencias y me ayuda a distinguir los picos efímeros de la carga sostenida.
Por qué los valores altos suelen indicar problemas de E/S
Puede producirse una carga elevada aunque la CPU apenas esté trabajando; en ese caso, las colas de E/S se bloquean. Hilos. Compruebo con top o htop la proporción %wa (espera de E/S) y utilizo iotop para ver qué procesos ralentizan el almacenamiento. A menudo, la causa son bases de datos que responden lentamente, tareas de copia de seguridad o unidades de red sobrecargadas. Si %wa aumenta, una actualización de la CPU no sirve de mucho; un almacenamiento más rápido, el almacenamiento en caché y menos sincronizaciones tienen un efecto más fuerte. El artículo ofrece una buena explicación detallada al respecto. Entender la espera de E/S, al que recurro cuando las esperas se prolongan demasiado.
Malentendido: la carga es igual al uso de la CPU.
Hago una distinción estricta entre los valores porcentuales de la CPU y el promedio de carga como métrica de cola. Una carga de 8 en un servidor de 8 núcleos puede ser normal si todos los núcleos están funcionando y no hay nada en espera. La situación se vuelve crítica cuando la carga es significativamente superior al número de núcleos y, al mismo tiempo, la curva de 15 minutos aumenta. Para ver las correlaciones, coloco CPU%, I/O-Wait, tiempos de programación y listas de procesos uno al lado del otro. Solo la interacción de estas señales me explica si la máquina está calculando, bloqueada o simplemente procesando muchos trabajos de corta duración.
Clasificar correctamente los picos en lugar de alarmarse
Los picos de carga breves provocados por Cron, la rotación de registros o las copias de seguridad forman parte del día a día y no significan automáticamente Avería. Siempre evalúo la hora del día, la duración y la línea de 15 minutos antes de activar alarmas o añadir capacidad. Escalo los umbrales con el número de núcleos, por ejemplo, la alarma solo se activa cuando la carga es superior a 2× núcleos durante varios minutos. Además, compruebo los picos irregulares en los sistemas de gestión de contenidos en busca de tareas en segundo plano; en WordPress, la nota es adecuada. Tareas cron de WP y carga. De este modo, evito reacciones precipitadas y doy prioridad a las medidas que aportan beneficios.
Leer el promedio de carga en el día a día del alojamiento web
Empiezo con uptime para echar un vistazo rápido y luego abro htop, para ver los procesos, la distribución de la CPU, la RAM y la E/S. Si la carga de 15 minutos sigue siendo alta, busco los culpables con iotop o pidstat. En el caso de cargas de trabajo con gran volumen de bases de datos, compruebo las latencias de las consultas, los índices y los aciertos de la caché. En los servidores web, compruebo si hay demasiados trabajadores PHP simultáneos en espera o si, en caso necesario, interviene OpCache. Esta rutina separa los síntomas de las causas y me ahorra costosas y ineficaces actualizaciones de hardware.
| Métricas | La vida cotidiana | Señal de advertencia (4 núcleos) | Siguiente paso |
|---|---|---|---|
| Carga 1 min. | <4 | >8 durante 3-5 min | Revisar los procesos principales |
| Carga 15 min. | <3 | >6 en aumento | Planificar la capacidad/arquitectura |
| CPU% | <80% | >95% permanente | Optimizar código/trabajador |
| Espera de E/S | <10% | >20% Puntas | Comprobar almacenamiento/caché |
Herramientas para una supervisión limpia del alojamiento web
Combino Métricas agentes con registros y trazas para encontrar las causas más rápidamente. Para las series temporales utilizo Prometheus u otros recopiladores alternativos, visualizados en Grafana. En cuanto a la infraestructura, utilizo Zabbix para las comprobaciones y las reglas de alarma flexibles, así como servicios SaaS para obtener paneles de control rápidos. Es importante tener una visión uniforme de la carga, CPU%, RAM, intercambio, latencias de disco y red. Sin una línea de tiempo común, la interpretación de los valores de carga sigue siendo fragmentaria.
| Categoría | Ejemplo | Puntos fuertes |
|---|---|---|
| Código abierto | Zabbix | Comprobaciones, agente, lógica de alarma |
| Series temporales | Prometeo | Modelo Pull, PromQL |
| visualización | Grafana | Paneles de control, alertas |
| SaaS | Datadog | Integraciones, APM |
Optimización con una carga elevada permanente
Empezaré por el dolor más intenso: el lento. Consultas, rutas de E/S bloqueadas o demasiados trabajadores simultáneos. Los índices de bases de datos, los grupos de conexiones y las cachés de consultas como Redis o Memcached reducen notablemente el tiempo de espera. A nivel de aplicación, alivio la carga del origen: almacenamiento en caché de páginas, fragmentos y objetos, así como un procesamiento limpio de colas. En el sistema, configuro vm.swappiness adecuadamente, compruebo las páginas enormes y establezco límites razonables para los servicios. Solo cuando se agota el software, escalo verticalmente (más RAM/CPU) u horizontalmente (más instancias con equilibrador de carga).
Promedio de carga en sistemas multinúcleo
Siempre calculo la carga en relación con Núcleos: La carga 16 puede estar bien en 16 núcleos físicos. La tecnología Hyper-Threading duplica las CPU lógicas, pero el rendimiento real no siempre es lineal, por lo que también evalúo las latencias. En contenedores o máquinas virtuales, las cuotas de CPU, las cuotas CFS y los límites influyen, lo que aparentemente distorsiona los valores „normales“. Una mirada al estrangulamiento de la CPU y a los tiempos de espera del programador separa los límites estrictos de los problemas reales de capacidad. Para tomar decisiones claras, la curva de 15 minutos me ayuda como referencia de tendencia.
Alojamiento compartido, vecinos y cuellos de botella ocultos
En entornos compartidos, la influencia de vecinos a menudo más potente que la propia aplicación. Por eso, observo además el robo de CPU, los tiempos de preparación y la contienda por el almacenamiento para detectar cargas externas. Si se „roban“ núcleos, la carga sigue aumentando a pesar de las optimizaciones propias. Como base para la toma de decisiones, utilizo la guía sobre Tiempo de robo de CPU y planifico recursos específicos cuando es necesario. De este modo, garantizo un rendimiento previsible en lugar de quedarme estancado en un cuello de botella.
Configurar correctamente las tendencias, los umbrales y las alarmas
Calibro umbrales por Núcleo y establezco una histéresis para que las alarmas no se activen con cada pico. Para 4 núcleos, inicio las alarmas aproximadamente con una carga > 8 durante varios minutos y las confirmo con una tendencia de 15 minutos. Excluyo las ventanas de mantenimiento y los tiempos de procesamiento por lotes de la evaluación para que los gráficos no muestren información errónea. Además, utilizo la detección de anomalías en comparación con la mediana histórica propia, en lugar de perpetuar valores fijos rígidos. De este modo, reacciono rápidamente ante cambios reales sin cansar al equipo con falsas alarmas.
Cómo Linux cuenta realmente la carga
Si es necesario, echo un vistazo bajo el capó: el núcleo calcula la longitud media de la cola de ejecución y cuenta no solo los subprocesos que se están ejecutando activamente (estado „R“), sino también los que se encuentran en sueño ininterrumpido („D“, normalmente estado de espera de E/S). Esto explica precisamente los altos valores de carga con un bajo uso de la CPU: muchos subprocesos se bloquean en el núcleo debido a discos lentos, accesos a la red o NFS. En /proc/loadavg Veo las tres medias y, además, los subprocesos „en ejecución/totales“, así como el último PID. Los zombis no influyen en este caso, pero los subprocesos del núcleo y los subprocesos de usuario se tienen en cuenta por igual. En sistemas con muchas tareas de corta duración (compilaciones, trabajadores), el valor de 1 minuto varía naturalmente más, mientras que el valor de 15 minutos sigue siendo mi referencia de estabilidad.
Para mí, es importante traducir „carga“ como „tiempo de espera“: si la carga supera claramente el número central, se forman colas. Esto no tiene por qué ser malo si se trata de trabajos de corta duración, pero si al mismo tiempo aumenta la latencia de las solicitudes, el sistema se sobrecarga. Por eso, siempre considero la carga junto con Tiempo de ejecuciónMétricas (Req-Latency, ttfb) para evaluar las colas no solo en términos numéricos, sino también en función de su impacto.
Presión de memoria, intercambio y bloqueos ocultos
A menudo veo valores de carga constantemente altos en presión de almacenamiento. Cuando la caché de páginas se reduce o kswapd desplaza páginas, los procesos entran en estado de espera. El intercambio genera E/S y ralentiza todo. Estoy comprobando vmstat (si/so), fallos importantes de página, /proc/meminfo (Cached, Dirty, Writeback) y observa si las latencias de E/S aumentan al mismo tiempo. Una carga elevada con CPU% moderada y un „await“ de disco creciente es para mí una señal clara: falta RAM o el conjunto de datos no cabe en la caché.
Reacciono por etapas: primero identifico los puntos críticos de la RAM (por ejemplo, grandes ordenaciones, consultas sin caché, enormes matrices PHP), luego refuerzo las cachés y vm.swappiness Configurarlo de manera que la memoria RAM no se desplace demasiado pronto. Desactivar completamente el intercambio rara vez es aconsejable: un intercambio pequeño y rápido (NVMe) con un uso disciplinado evita los picos del OOM Killer. Si las escrituras se convierten en un cuello de botella, mitigo las oleadas de sincronización (opciones de procesamiento por lotes, registro en diario, vaciados asíncronos) y reduzco las escrituras simultáneas.
Contenedores, cgroups y limitación de CPU
En contenedores, interpreto «cargar» con respecto a cgroups. Las cuotas CFS limitan el tiempo de CPU por período; si se alcanza el límite, el contenedor sigue mostrando valores de carga elevados, aunque simplemente restringido . Lo compruebo. cpu.max (cgroup v2) o. cfs_quota_us/cfs_period_us (v1) y el contador del acelerador (cpu.stat). Si „throttled_time“ aumenta, la causa no es la falta de potencia de cálculo, sino los límites estrictos. En Kubernetes, distingo estrictamente entre „solicitudes“ (programación) y „límites“ (restricción): los límites mal establecidos generan colas artificiales.
La afinidad de la CPU y NUMA también influyen en la imagen: si los subprocesos se fijan en unos pocos núcleos o se aparcan en un nodo NUMA, la carga puede acumularse localmente, mientras que la CPU% global parece estar bien. Distribuyo los subprocesos activos de forma selectiva, compruebo el equilibrio de IRQ y me aseguro de que los contenedores no se concentren todos en los mismos núcleos físicos. De este modo, reduzco los tiempos de espera sin necesidad de actualizar el hardware.
Lista de verificación para una toma de decisiones rápida
- Carga relativa a Núcleos Evaluar (carga/núcleos ≈ 1 bueno, ≫1 crítico).
- CPU% y Espera de E/S Contrarrestar: ¿la caja calcula o espera?
- 15 minutos-Comprobar la tendencia: sobrecarga prolongada frente a pico breve.
- Procesos principales y estados (R/D/S/Z); muchos estados D = cuello de botella de E/S.
- Latencias del disco, medir la profundidad de la cola y %util; comprobar también las rutas NFS/red.
- RAM: Fallos de página, actividad de intercambio, kswapd: aliviar la presión sobre la memoria.
- Límites Comprobar en contenedores/máquinas virtuales: cuotas, recursos compartidos, robo, limitación.
- Concurrencia Limitar: trabajadores/subprocesos, colas, contrapresión.
- Picos temporales Trasladar: Cron, copias de seguridad, índices, ETL.
- reajustar, luego volver a medir: efecto antes del hardware.
Ejemplos concretos de optimización del alojamiento web
En pilas web/PHP, Concurrencia la mayor palanca. En PHP‑FPM, establezco valores realistas pm.max_hijos, para que las solicitudes no saturen la base de datos al mismo tiempo. En nginx o Apache, limito las conexiones ascendentes simultáneas, activo Keep-Alive de forma sensata y almaceno en caché los activos estáticos de forma agresiva. OpCache evita las tormentas de calentamiento, mientras que una caché de objetos (Redis/Memcached) reduce enormemente la carga de consultas.
En el caso de las bases de datos, empiezo con Indexación y planes. En lugar de aumentar las conexiones a ciegas, utilizo grupos de conexiones y limito las consultas simultáneas costosas. Observo las tasas de acierto del grupo de búferes, los tiempos de espera de bloqueo y los desbordamientos de tablas temporales. Los informes grandes o los trabajos de migración se ejecutan de forma asíncrona y por lotes; prefiero una carga constante de 60% a 5 minutos de 200% y luego un parón.
Para los ejecutables que consumen mucha memoria (por ejemplo, procesamiento de imágenes/vídeos), defino un límite máximo de trabajos simultáneos por host. Establezco agradable y ionice, para que los procesos por lotes no destruyan las latencias interactivas. En discos NVMe rápidos, mantengo la configuración del programador ágil, me aseguro de que haya suficiente profundidad de cola y evito las sincronizaciones chatty. De este modo, desaparecen las avalanchas de D-State y la carga disminuye sin que aumente CPU%: la máquina simplemente espera menos.
Ejecutar cargas de trabajo de compilación y por lotes de forma planificada
Durante la compilación o el renderizado, la carga se correlaciona fuertemente con la Paralelismo en el trabajo. Elijo -j Consciente: Núcleos × (0,8-1,2) es un buen comienzo, pero yo me refiero a RAM Es mejor tener menos trabajos paralelos estables que tormentas de intercambio con picos de carga. Las cachés de artefactos, las compilaciones incrementales y los volúmenes de E/S dedicados evitan que los estados D inflien la cola con muchos archivos pequeños.
Planifico las ventanas de procesamiento por lotes con poca carga. Las rotaciones, las copias de seguridad, el ETL y la reindexación se ejecutan de forma escalonada, no todo a la hora en punto. Las colas de trabajo reciben contrapresión: solo se aceptan nuevos trabajos si hay espacios libres, en lugar de simplemente „disparar y olvidar“. De este modo, la carga y las latencias se mantienen bajo control y los picos son predecibles.
PSI: Información sobre pérdida de presión como sistema de alerta temprana
Además de la carga clásica, utilizo la Información sobre pérdida por presión (PSI) de Linux en /proc/pressure/cpu, .../io y .../memoria. PSI muestra la duración de las tareas. colectivamente tuvieron que esperar, ideal para evitar la sobrecarga. principios de Si la presión de la CPU aumenta durante varios minutos, aunque CPU% sea moderada, sé que la cola de ejecución se está acumulando. Con la presión de E/S, puedo ver si las latencias de almacenamiento afectan a todo el sistema, incluso si los valores individuales de iotop parecen inofensivos.
Combino PSI con la carga de 15 minutos: si ambos aumentan, hay una saturación real. Si solo aumenta la carga, pero PSI se mantiene estable, es posible que se estén ejecutando muchos trabajos cortos que los usuarios no perciben. Esto da lugar a alarmas más claras y a mejores decisiones: aumentar los límites, equilibrar los trabajos o reforzar el hardware de forma específica allí donde se detectan cuellos de botella.
Breve resumen para llevar
Leo el Carga Nunca de forma aislada, sino en el contexto de núcleos, espera de E/S, CPU% y la curva de 15 minutos. Solo interpreto los valores altos después de examinar las latencias de almacenamiento y red, ya que ahí es donde suele estar el verdadero freno. Para las medidas, doy prioridad a los factores visibles: consultas, almacenamiento en caché, trabajadores, límites... y solo después, el hardware. En entornos compartidos, compruebo los efectos parásitos, como el robo, y, si es necesario, planifico recursos dedicados. Con estas reglas, tomo decisiones tranquilas y sólidas y mantengo las configuraciones de alojamiento fiables y rápidas.
