Como leer el uso de CPU en el top o el mpstat
Existe mucha confusión al interpretar el uso de la CPU mediante el top o mpstat. Una lectura incorrecta puede hacernos pensar que existe un determinado problema cuando en realidad es otro completamente diferente. Unos ejemplos serían:
Un ejemplo de salida del consumo de CPU del top sería:
Cpu(s): 3.6%us, 0.9%sy, 0.1%ni, 95.1%id, 0.3%wa, 0.0%hi, 0.1%si, 0.0%st
En el mpstat veríamos:
09:22:45 AM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s 09:22:45 AM all 3.58 0.09 0.94 0.26 0.01 0.05 0.00 95.07 24.42
Vamos a ver que significan sus campos:
- %user (en top: %us): Porcentaje de uso en el nivel de usuario
- %sys (en top: %sy): Porcentaje de uso en el nivel del sistema (kernel). En el computo no se incluyen interrupciones
- %iowait (en top %wa): Porcentaje del tiempo esperando operaciones de entrada/salida (I/O): Principalmente discos, red…
- %nice (en top %ni): Porcentaje del tiempo que un proceso de usuario se ejecuta con la prioridad variada con nice
- %irq (en top %hi): Porcentaje del tiempo sirviendo interrupciones de hardware.
- %soft (en top %si): Porcentaje del tiempo sirviendo interrupciones de software. Normalmente se tratan de llamadas al sistema, que se implementan mediante interrupciones de software.
- %steal (en top %st): En kernels superiores al 2.6.11 son los ciclos dedicados a tareas como la virtualización.
- %idle (en top %id): Tiempo en la que la CPU ha estado sin trabajo y sin estar esperando I/O
Resulta muy común que la gente se fije solamente en el indicador de %user (ni la suma de %user y %sys) para decidir como de ocupada esta la CPU. Aunque en algunos tipos de carga puede ser suficiente, no se puede generalizar porque un %user a 10% no significa que la CPU este libre, sino que puede estar esperando a discos. Así, debemos fijarnos también en el parámetro iowait.
Una mejor forma de ver rápidamente el consumo de CPU sería fijarnos en el idle, pero siempre se deben analizar el resto de indicadores.
Lo que finalmente nos debemos preguntar es: Es fiable esta información? Si y no, como todo muestreo tiene sus errores. En este caso la información de la CPU se recoge mediante la interrupción del timer, que mira en ese momento que esta haciendo la CPU por lo que podemos imaginar la siguiente situación:
- Salta el timer, la CPU esta en el handler IDLE, por lo que se registra como tal y sigue.
- Ocurre una interrupción y se sirve antes que vuelva a saltar el timer
- Salta el timer, la CPU vuelve a estar con el handler IDLE, por lo que consideramos que todo el periodo ha estado IDLE
Esto no significa que los datos no sean fiables, simplemente que, como en todo muestreo, hay un error a tener en cuenta.
Relacionados
Imprimir
12. November 2009 at 12:35 pm :
Excelente artículo, me quito el sombrero. Es cierto lo que dices, yo siempre le he visto “problemas” a la monitorización de los parámetros del sistema debido al ciclo de muestreo. Sobre todo en sistemas con poca carga o con procesos puntuales y de corta duración.
Por ejemplo munin te muestra unos registros muy buenos, pero con una frecuencia de muestreo de 5 minutos es muy problable que no vea muchos procesos.
Otro ejemplo es intentar averiguar el coste de recursos de una herramienta de monitorización como mpstat o vmstat. Si durante su funcionamiento, a un muestreo x1, se activa por ejemplo top con un muestreo x2, posiblemente no lleguen a “medirse” entre ellos nunca…
17. November 2009 at 10:38 am :
Muchas gracias
Una aclaración, referente al periodo de muestreo me refiero a como el kernel muestrea el uso de CPU. Me prepararé otro artículo referente a como las aplicaciones usan el procfs para obtener datos para aclarar un poco este punto.
saludos!
4. February 2011 at 5:18 pm :
Muy bueno el articulo gracias por el mismo.