Solución:
hi es el tiempo empleado en procesar las interrupciones de hardware. Las interrupciones de hardware son generadas por dispositivos de hardware (tarjetas de red, controlador de teclado, temporizador externo, sensores de hardware, …) cuando necesitan señalizar algo a la CPU (los datos han llegado, por ejemplo).
Dado que esto puede suceder con mucha frecuencia, y dado que esencialmente bloquean la CPU actual mientras se está ejecutando, los manejadores de interrupciones de hardware del kernel están escritos para ser lo más rápidos y simples posible.
Si es necesario realizar un procesamiento largo o complejo, estas tareas se aplazan mediante una llamada al mecanismo softirqs. Estos se programan de forma independiente, pueden ejecutarse en cualquier CPU, incluso pueden ejecutarse simultáneamente (nada de eso es cierto para los controladores de interrupciones de hardware).
La parte sobre las IRQ estrictas que bloquean la CPU actual y la parte sobre softirqs poder ejecutarse en cualquier lugar no son exactamente correctos, puede haber limitaciones y algunas IRQ duras pueden interrumpir a otras.
Como ejemplo, una interrupción de hardware de “datos recibidos” de una tarjeta de red podría simplemente almacenar la información “la tarjeta ethX necesita ser reparada” en algún lugar y programar una softirq. los softirq sería lo que desencadena el enrutamiento de paquetes real.
si representa el tiempo pasado en estos softirqs.
Una buena lectura sobre el softirq El mecanismo (con un poco de historia también) es I’ll Do It Later de Matthew Wilcox: Softirqs, Tasklets, Bottom Halves, Task Queues, Work Queues and Timers (PDF, 64k).
st, “robar tiempo”, solo es relevante en entornos virtualizados. Representa el momento en el que la CPU real no estaba disponible para la máquina virtual actual: el hipervisor la “robó” de esa VM (ya sea para ejecutar otra VM o para sus propias necesidades).
El documento de contabilidad del tiempo de la CPU de IBM tiene más información sobre el tiempo de robo y la contabilidad de la CPU en entornos virtualizados. (Está dirigido a hardware de tipo zSeries, pero la idea general es la misma para la mayoría de las plataformas).
- us – Tiempo empleado en el espacio de usuario
- sy: tiempo empleado en el espacio del kernel
- ni – Tiempo empleado en ejecutar procesos de usuario precisos (prioridad definida por el usuario)
- id: tiempo empleado en operaciones inactivas
- wa: tiempo dedicado a esperar en los periféricos de E / S (p. ej., disco)
- hi: tiempo empleado en el manejo de rutinas de interrupción de hardware. (Siempre que una unidad periférica desee atención de la CPU, literalmente tira de una línea para indicarle a la CPU que la repare)
- si: tiempo empleado en el manejo de las rutinas de interrupción del software. (un fragmento de código, llama a una rutina de interrupción …)
- st: tiempo empleado en esperas involuntarias por parte de la CPU virtual mientras el hipervisor está dando servicio a otro procesador (robado de una máquina virtual)
El valor “st” se puede explicar simplemente mediante el uso de una instancia T2.micro EC2 de AWS.
En la documentación de AWS, puede leer que solo obtiene un rendimiento de referencia del 10% por CPU virtual. Esto significa que si tiene un proceso que consumiría mucho tiempo de la CPU, el valor “st” permanecerá alrededor de 90 ya que solo se le permite usar el 10% de la VCPU. La suma de los demás valores se mantendrá alrededor de 10.
Por tanto, AWS utiliza el hipervisor para permitirle acceder únicamente a una determinada cantidad de potencia informática. Lo ralentiza intencionalmente, ya que solo está utilizando un tipo de instancia de nivel bajo.
Espero que esto haga las cosas un poco más fáciles de entender.