Linux PSI Me proporciona métricas que muestran cuánto tiempo esperan las tareas en la CPU, la memoria o las E/S, lo que permite identificar los verdaderos cuellos de botella. De este modo, puedo detectar con precisión cuándo se bloquean los sistemas, en lugar de limitarme a medir la carga, y, a partir de los valores de «Pressure», deducir medidas directas para el análisis del rendimiento y la supervisión.
Puntos centrales
- parcial/completo: Señal de alerta temprana frente a bloqueo crítico
- CPU/memoria/E/S: Carga por recurso claramente diferenciada
- avg10/60/300: Intervalo de tiempo para la evaluación de tendencias
- Cgroups: Identificar a los responsables y a los afectados
- Disparador: Reaccionar automáticamente cuando se supera el umbral
Qué mide el PSI de Linux y por qué es importante
Voy a leer un fragmento de Presión-Las métricas indican cuánto tiempo de trabajo real pierden los procesos debido a la falta de tiempo de CPU, RAM o E/S. Los valores clásicos de utilización solo muestran en qué medida se utilizan los recursos, mientras que PSI revela con qué frecuencia el sistema se detiene de hecho. Esto es precisamente lo que permite distinguir entre una cola corta y un bloqueo total. En entornos dinámicos con contenedores y despliegues densos, esto me permite detectar los cuellos de botella antes y asignarlos claramente a un recurso concreto. De este modo, priorizo las medidas de optimización de forma específica y me ahorro tener que adivinar cuál es la verdadera Causa.
Activar y comprobar PSI en Linux
Primero compruebo si PSI está activo consultando los archivos que se encuentran en /proc/pressure Si leo y veo que la CPU, la memoria y las E/S proporcionan valores allí, todo está listo. Si faltan datos, activo PSI con el parámetro de arranque del kernel `psi=1` o me aseguro de que `CONFIG_PSI=y` esté configurado en el kernel. Esta función está disponible a partir del kernel 4.20 y, a menudo, ya viene activada en las distribuciones actuales. Para comprobaciones rápidas, bastan simples comandos como `cat /proc/pressure/cpu`, que me proporcionan los valores avg10, avg60, avg300 y total. Así sé en cuestión de segundos si mi sistema ofrece datos significativos Métricas proporciona.
Entender los archivos de /proc/pressure
En /proc/pressure hay tres archivos para CPU, memory e io, que muestran cada uno dos tipos de salida: «some» y «full». «Some» indica que al menos una tarea ha tenido que esperar, mientras que «full» señala que todas las tareas que no están inactivas se han bloqueado simultáneamente. Además, obtengo medias móviles de 10, 60 y 300 segundos, así como un valor total acumulado. A partir de estos intervalos de tiempo, distingo entre picos breves y problemas persistentes. De este modo, evalúo con objetividad si solo se producen picos aislados o si se trata de una situación persistente Presión está disponible.
«some» frente a «full» en la práctica
Considero «some» como un indicador temprano y «full» como una alarma grave, ya que «full» describe fases en las que el trabajo productivo se detiene de hecho. Si «some» aumenta en la CPU, compruebo la programación, los bloqueos y la distribución de la carga; en ese caso, puede ser útil optimizar los hilos o medir el Medir la latencia del programador. Los valores elevados de «memory-some» suelen indicar recuperaciones de páginas, intercambio de memoria o asignaciones que consumen muchos recursos. Si «io-some» aumenta, reviso las colas, las prioridades y los accesos concurrentes. No tomo decisiones basándome en corazonadas, sino en criterios claros Señales.
Evaluación a nivel de sistema frente a la basada en cgroups
En primer lugar, analizo a nivel de todo el sistema Valores, para obtener una visión general, y después paso a Cgroups para identificar las fuentes. Con cgroup v2 encuentro archivos «pressure» específicos para cada servicio o contenedor, lo que me permite asignarlos a pods, slices o unidades. Este procedimiento separa los síntomas de las fuentes, en lugar de atribuir todas las cargas de forma generalizada al host. A continuación, ajusto de forma específica las cuotas, las participaciones de CPU o los límites de memoria. De este modo, aumento la equidad y reduzco las interferencias mutuas Influencia.
PSI en monitorización, paneles de control y Kubernetes
Rara vez recopilo datos PSI manualmente, sino que utilizo el programa Exporter para que exporte los datos como series temporales recopilar para que los paneles de control muestren tendencias y correlaciones. En Kubernetes, leo los PSI a nivel de nodo, pod y contenedor, lo que permite una separación clara entre el consumo y los cuellos de botella por cada carga de trabajo. De este modo, puedo detectar si un único pod aumenta los tiempos de espera para los demás o si el problema se produce a nivel de todo el nodo. Configuro alertas para aumentos completos y para valores «some» persistentemente altos. Esto me permite reaccionar de forma proactiva antes de que los usuarios sufran tiempos de espera siente.
Situaciones típicas de uso y umbrales recomendables
Utilizo PSI en las pruebas de carga para comprobar si los tiempos de respuesta aumentan debido a la sobrecarga de la CPU, la memoria o las E/S, y si esto ocurre solo de forma momentánea o de manera permanente. En la planificación de la capacidad, superviso el indicador «avg300» para detectar patrones recurrentes y ampliar los recursos o reubicar las cargas de trabajo a tiempo. Para el autoescalado, utilizo desencadenantes cercanos al umbral en el que se produce el estado «full», para poder reaccionar a tiempo. En caso de un deterioro progresivo del rendimiento, comparo las líneas de referencia antes y después de los lanzamientos para hacer visibles los efectos. De este modo, tomo decisiones basadas en hechos e invierto donde más Efecto se levanta.
Tabla de verificación rápida de las métricas PSI
Cuando analizo el PSI, utilizo una clasificación sencilla que me permite llegar más rápido a la hipótesis correcta. La siguiente tabla resume la interpretación de «some» y «full» por recurso y ofrece unas primeras opciones de actuación. No sustituye a un análisis más profundo, pero me ahorra un tiempo valioso durante el funcionamiento. Lo fundamental sigue siendo valorar de forma diferente los picos de corta duración respecto a las fases más prolongadas. Precisamente para ello utilizo los valores promediados avg10, avg60 y avg300 como Contexto.
| Recursos | señal «some» | Señal completa | Causas frecuentes | Posibles medidas |
|---|---|---|---|---|
| CPU | Periodos de espera ocasionales | Todas las tareas están bloqueadas | Conflictos del programador, bloqueos, exceso de subprocesos | Ajustar los grupos de subprocesos, suavizar los bloqueos, ajustar las cuotas y los porcentajes de uso de la CPU |
| Memoria | Recuperaciones, errores de página, atascos de asignación | Fuerte presión, el swap domina | Sobreasignación, montones grandes, presión en la caché | Comprobar los límites, optimizar las asignaciones, reducir el intercambio |
| E/S | Colas cada vez más largas | I/O es un término genérico | Discos/red sobrecargados, accesos simultáneos | Prioridades, procesamiento por lotes, ajuste de colas, volúmenes independientes |
Interpretar correctamente la presión del acumulador
Analizo el valor de «memory.pressure» junto con el RSS, los porcentajes de caché y el uso del swap, ya que solo esta combinación ofrece conclusiones fiables. A menudo, detrás de un valor elevado de «some» se esconde una fase de liberaciones intensivas o un aumento de los «page-faults», que se puede suavizar con mejores patrones de asignación. Si aparece «full», detengo los experimentos y, en primer lugar, reduzco la presión mediante límites o cachés menos agresivas. Para profundizar en el tema, me sirve de ayuda Presión de memoria con consejos prácticos sobre cómo optimizar la memoria RAM. Así evito que el intercambio incontrolado de datos afecte a los tiempos de respuesta dominado.
Detectar y resolver los cuellos de botella de E/S
Analizo io.pressure junto con las latencias, las tasas de re-colocación en cola y las profundidades de cola, ya que los valores puros de rendimiento ocultan los cuellos de botella. Un valor elevado de «some» con una carga moderada suele indicarme perfiles de acceso irregulares, que pueden suavizarse mediante el procesamiento por lotes o la priorización. En caso de retrasos en el primer byte y un «full» creciente, apuesto por la desacoplamiento mediante E/S asíncrona y volúmenes separados para las rutas de acceso más frecuentes. Para diagnósticos detallados, utilizo series de mediciones y la guía, de probada eficacia en el día a día, sobre Analizar la espera de E/S. De este modo, tomo decisiones acertadas en lugar de Supuestos.
PSI frente a la carga media y las métricas clásicas
Comparo deliberadamente el PSI con el promedio de carga, la utilización de la CPU, el iowait y la utilización de la memoria para subsanar las lagunas entre estas perspectivas. Una carga elevada con una presión de la CPU baja a menudo solo me indica que hay muchas tareas que pueden procesarse activamente, sin atascos en todo el sistema. Por el contrario, un aumento de la presión de la CPU (cpu.pressure) con una carga moderada es un indicio de conflictos en el programador o de contienda por bloqueos. En cuanto a la E/S, lo siguiente: el iowait por sí solo no me indica en qué medida se ve afectado el sistema en su conjunto; el io.pressure cuantifica cuánto tiempo de trabajo se pierde en el proceso. Es precisamente esta conversión de “carga” en “tiempo perdido” lo que hace que mis decisiones sean mucho más fiables.
Ventana «avg» y lectura totalmente precisa
Considero que los valores avg10/60/300 representan el porcentaje de tiempo durante el cual las tareas han estado bloqueadas. Un valor de avg10 de 2,50 significa que, en los últimos 10 segundos, se han perdido 2,51 TP3T del tiempo de trabajo potencial. El valor «total» acumula el tiempo de bloqueo desde el arranque (en unidades de tiempo de alta resolución) y, de este modo, me muestra el Área bajo la curva. Para la planificación de la capacidad, analizo la pendiente de los perfiles diarios en su conjunto: si la línea se vuelve notablemente más pronunciada en las fases de máxima actividad, planifico medidas para aliviar la carga. En cuanto a los indicadores operativos, evalúo los patrones: un breve repunte en el avg10 me preocupa menos que un aumento paralelo del avg60 y el avg300, lo cual indica una presión estructural.
Cgroups en la práctica: estructura, rutas y permisos
Trabajo con cgroup v2 utilizando los archivos «pressure» directamente en los directorios correspondientes de los servicios, las «slices» o los pods. De este modo, puedo detectar, para cada unidad, pod o contenedor, si la presión se genera localmente o si simplemente se transmite. De esta forma, se pueden diferenciar claramente las unidades de systemd, los pods de Kubernetes y los grupos definidos por el usuario. Si la asignación es correcta, aplico restricciones de forma selectiva: cuotas de CPU más estrictas, repartos de CPU más equitativos y límites de memoria realistas. En la práctica, me aseguro de realizar la medición allí donde surte efecto: precisamente en el Cgroup que establece los límites. Esto evita que combata los síntomas en un lugar, mientras que la fuente real permanece intacta.
Estrategias de notificación sin saturación de alertas
Defino las alertas de manera que tengan en cuenta las tendencias y la persistencia. Para la detección temprana, establezco los umbrales en «some», los combino con ventanas de observación e histéresis, y compruebo si avg10 y El valor «avg60» debe mantenerse elevado. Para intervenciones urgentes, vinculo el valor «full» a ventanas cortas y reacciones automáticas (escalado, priorización, limitación). Para evitar fluctuaciones, no activo la respuesta hasta que un estado se haya confirmado varias veces, y solo vuelvo a revertirla cuando los valores caen significativamente por debajo del umbral de retorno. Vinculo las alertas a los SLO de los servicios: si las latencias p95 aumentan y, al mismo tiempo, crece la carga, el hallazgo es fiable; la mera carga de trabajo por sí sola no me basta para ello.
Ejemplos prácticos: patrones que reconozco al instante
Me gusta recopilar patrones recurrentes porque agilizan la toma de decisiones:
- CPU: “Contendencia por el bloqueo” en lugar de «demasiado pocos núcleos» – cpu.some aumenta, aunque la carga de la CPU no esté al límite. Analizo los «hotlocks», reduzco la dispersión de subprocesos y suavizo los picos con contrapresión. Esto suele ser más eficaz que añadir núcleos adicionales.
- Memory: Espiral de recuperación – El valor de «memory.some» aumenta y fluctúa con los errores de página, mientras se activa el intercambio. Reduzco la agresividad de la caché, disminuyo los picos del montón (por ejemplo, el tamaño de los lotes), ajusto los límites y, de este modo, evito que «memory.full» llegue a aparecer.
- E/S: Accesos desequilibrados – io.some aumenta mientras que el rendimiento general se mantiene normal. Desacoplo las rutas de lectura y escritura, agrupo las pequeñas operaciones de E/S en lotes y distribuyo las rutas más cargadas en volúmenes independientes. De este modo, reduzco los tiempos de espera sin aumentar necesariamente el rendimiento puro.
Límites y obstáculos en la interpretación
Tengo presente que PSI mide el tiempo de espera, no la carga absoluta. Un trabajo por lotes que depende de la CPU puede mostrar una carga elevada sin aumentar el cpu.pressure, siempre que haya suficientes núcleos disponibles. Por el contrario, un bajo rendimiento con un io.pressure elevado puede indicar un claro atasco. En entornos virtualizados, compruebo además si los límites o las afinidades generan cuellos de botella locales: un contenedor que solo está asignado a unos pocos núcleos puede mostrar una elevada cpu.pressure, aunque el host disponga de recursos libres. También es importante comparar la visión a nivel del sistema con la local del cgroup; solo así puedo determinar si estoy resolviendo el problema en el lugar adecuado.
Pautas operativas: muestreo, gastos generales y visualización
Mantengo el muestreo sencillo: un intervalo de 1 a 5 segundos me basta para tomar decisiones operativas, ya que las ventanas de promedio ya suavizan los datos. Considero que la sobrecarga de PSI es insignificante, sobre todo porque mantengo la medición cerca del sistema y solo recojo unas pocas series temporales bien situadas. Para la visualización, coloco paneles uno al lado del otro por cada recurso (some/full, avg10/60/300, total) y los correlaciono con las tasas de latencia y de errores. En los análisis retrospectivos, trazo la pendiente del valor «total» en función de las implementaciones, las versiones o los cambios de configuración; de este modo, queda claro qué medidas reducen realmente la presión.
Medidas específicas para cada recurso
A partir de los patrones, deduzco medidas concretas sin recurrir de forma instintiva a añadir hardware:
- CPU: Limitar los grupos de subprocesos y los controles de concurrencia, mitigar los «hotlocks» (granularidad/estrategia de bloqueo), distribuir la carga de forma equitativa (porciones/cuotas), tener en cuenta la topología (NUMA, afinidad). Solo cuando la descarga local no surta efecto, escalaré horizontal o verticalmente.
- Memoria: Estabilizar las asignaciones (agrupación por lotes, búferes), controlar las cachés, establecer límites realistas, suavizar los picos del montón y reducir la influencia del intercambio. Realizo mediciones específicas antes y después de los cambios, ya que memory.some es muy sensible a los patrones de asignación.
- E/S: Suavizar los perfiles de acceso (procesamiento por lotes, E/S asíncrona), desacoplar las rutas críticas, establecer prioridades, seleccionar adecuadamente la profundidad de las colas y separar las cargas de trabajo que compiten entre sí. Evalúo los resultados en función de la disminución de la presión de E/S y de la reducción de las latencias P99.
El PSI en el día a día del equipo: comunicación y sentido de la responsabilidad
Yo también utilizo PSI como lenguaje común entre los equipos de la plataforma y los de producto. En lugar de hablar de forma abstracta de “lento”, nombro el recurso y el patrón: “io.some avg60 por encima de 4% desde hace 20 minutos en el servicio X” o “memory.full se activa en el cgroup Y”. Esta precisión facilita la priorización, ya que queda claro qué responsables deben actuar y qué presupuesto (tiempo, recursos) promete los mayores resultados. A través de líneas de referencia definidas, acuerdo objetivos de calidad que sean técnicamente sólidos y comprensibles para las partes interesadas.
Desencadenantes, líneas de base e implementación gradual
Utilizo PSI-Trigger con valores umbral y ventanas de observación para que un daemon reaccione automáticamente cuando la presión se mantenga elevada. Para obtener resultados fiables, antes de realizar cambios establezco una línea de referencia basada en las fases de carga habituales, que luego comparo con nuevas series de mediciones. Defino las alertas de forma conservadora: el nivel «some» (elevado de forma prolongada) me da tiempo para actuar, mientras que el nivel «full» (máximo) activa las medidas correctivas. En flotas grandes, implemento las alertas basadas en PSI por etapas para evitar el ruido y ajustar las tolerancias con precisión. De este modo, mi sistema de monitorización borrar y con capacidad de trabajo, sin saturar a los equipos con notificaciones innecesarias.
Ventajas para el alojamiento web, la virtualización y los entornos multitenant
Con PSI compruebo si algunas cargas de trabajo ralentizan a otras, si las reservas de hardware son suficientes y dónde hay que ajustar los límites. En entornos compartidos, detecto la presión constante sobre la CPU, la memoria o las E/S que generan cuentas concretas y planifico los reasignaciones con antelación. Los valores basados en cgroups me indican qué servicios se ven afectados y dónde debo limitar o priorizar de forma específica. De este modo, mantengo unos tiempos de respuesta fiables y garantizo un uso equitativo de los recursos, incluso bajo carga. Esto reduce los costes, evita que la situación se agrave y aumenta la calidad.
Conclusión: los indicadores se convierten en decisiones
Utilizo Linux PSI porque permite cuantificar los tiempos de espera y, de este modo, reduce la brecha entre la carga del sistema y la experiencia del usuario. Con «some» detecto señales tempranas, con «full» reacciono ante bloqueos reales y con «Cgroups» localizo las causas exactas. Los paneles de control, los disparadores y las líneas de referencia transforman esta visión en medidas concretas: límites optimizados, mejor distribución de la carga y rutas de E/S limpias. Quien utiliza PSI de forma activa reduce el tiempo necesario para identificar la causa y se ahorra muchas rondas de ajuste a ciegas. De este modo, los datos de monitorización se convierten en Decisiones, que hacen que los sistemas funcionen notablemente más rápido.
