Pasé por un problema en el que solo podía adivinar qué proceso estaba consumiendo la CPU.
El uso de mi CPU fue aproximadamente del 80% para todos los núcleos en psensor.
Lo intenté htopy (el último lo intenté incluso con sudo sin éxito). Todos estos mostraron que el pid culpable (que yo conocía) usaba aproximadamente el 7% solo...topps -A -o pcpu,pid,cmd --sort +pcpu
Cuando hago SIGKILL en ese pid, todo vuelve a la normalidad.
Para probar, hice un bucle infinito en la terminal while true;do echo -n;donepero que pude ver claramente en htop; así que supongo que lo que estaba causando el problema no era similar a eso...
Entonces me pregunto si hay otras formas en que podría haber encontrado al culpable sin tener que adivinar.
Pensando de nuevo, creo que me gustaría saber qué cálculos psensory usos del "subprograma indicador de carga del sistema" pudieron mostrar ese valor pero los demás no pudieron.
PD.:enlace sobre el tiempo de espera, vinculando sobre el promedio de carga
Respuesta1
No estoy lo suficientemente familiarizado con los detalles como para dar sugerencias precisas, pero supongo que hay dos fuentes de diferencias entre la carga real causada y el uso de CPU mostrado:
El proceso puede constar de varios subprocesos y
topes posible que no los resuma. Puedes ver el número de hilos mediante esto:ps -eo pid,nlwp,%cpu,user,argsEn
toppuedes cambiar el manejo del hilo conH. El uso de CPU de cada subproceso suele ser bastante bajo.El proceso puede causar muchas E/S. El tiempo de espera de E/S es parte de la carga general de la CPU, pero puede no ser parte del valor de uso de la CPU de un proceso. Entonces verifique el
waitvalor entop. No indica qué procesos lo causan y en qué medida, pero si el valor es bajo, no puede explicar el efecto.
Respuesta2
El código ejecutado en un sistema Unix se clasifica como código de kernel o código de usuario. El código de dominio del usuario siempre está adjunto a un proceso, por lo que si la CPU está ocupada ejecutando el código de dominio del usuario, se muestra en alguna línea en top. El código del kernel normalmente se adjunta a un proceso: si el kernel está ejecutando una llamada al sistema, entonces el procesamiento interno del kernel se considera perteneciente a ese proceso. La hora del kernel es la "hora del sistema" informada por la timeutilidad.
Algunas de las cosas que hace el kernel no pueden contabilizarse directamente en un solo proceso. En particular, las interrupciones de hardware no pertenecen intrínsecamente a un proceso en particular. Por ejemplo, supongamos que la tarjeta de red activa una interrupción. El kernel ejecuta código para leer y analizar el paquete de red; hasta el momento no hay ningún proceso involucrado. El paquete puede rechazarse mediante una regla de firewall, en cuyo caso ningún proceso puede reclamar ese tiempo de procesamiento. Si un proceso termina recibiendo ese paquete, parte del tiempo de recepción se pondrá en la pestaña de ese proceso, pero no en las primeras etapas.
Entonces es posible tener tiempo de CPU que no pertenezca a ningún proceso. Sin embargo, a veces ese tiempo de CPU es causado indirectamente por algún proceso. Por ejemplo, si hay un proceso que envía paquetes a otra máquina y hace que esta otra máquina responda, pero el firewall bloquea los paquetes de respuesta, entonces el tiempo dedicado a analizar y descartar los paquetes de respuesta no se remontará a ese proceso de envío; pero si el proceso de envío se detiene, lo que hace que la máquina remota deje de responder, entonces el núcleo ya no perderá tiempo rechazando los paquetes. Por supuesto, la red es sólo un ejemplo; hay muchas otras formas en que el núcleo puede hacer cosas que no se pueden rastrear directamente hasta un proceso.
No ha proporcionado suficiente información para estar seguro de que esto es lo que está sucediendo (y puede ser difícil saberlo sin un depurador del kernel), pero esta es una explicación plausible.
Respuesta3
Si no desea utilizar htop,ps,top, puede utilizar systemtap, para obtener más detalles de bajo nivel.