Como todos sabemos, una carga de 1.00 en un solo procesador significa que hay una carga del 100% . Analógicamente, una carga de 4.00 en un núcleo cuádruple sería del 100% .
¿Cómo debo interpretar la carga en un procesador de 4 hilos y 8 hilos? ¿Cuándo alcanzo la capacidad máxima de la CPU? ¿A las 4.00 o las 8.00 ?
Respuestas:
No seguramente, pero sobre todo en 1.00*n_cpu.
La carga significa lo siguiente: si hay múltiples procesos en un sistema de una sola CPU, se están ejecutando aparentemente en paralelo. Pero no es cierto. Lo que prácticamente sucede: el núcleo le da 1/100 de segundo a un proceso y luego interrumpe su funcionamiento con una interrupción. Y le da el siguiente 1/100 de segundo a otro proceso.
Prácticamente la pregunta, "¿qué proceso debería obtener nuestro próximo intervalo de 1/100 segundos?", Será decidida por una heurística compleja. Se nombra como programación de tareas .
Por supuesto, los procesos que están bloqueados, por ejemplo, están esperando sus datos de lo que están leyendo del disco, están exentos de esta programación de tareas.
Qué carga dice: cuántos procesos están esperando actualmente su próximo marco de tiempo de 1/100 segundos. Por supuesto, es un valor medio. Esto se debe a que puede ver varios números en a cat /proc/loadavg.
La situación en un sistema multi-CPU es un poco más compleja. Hay múltiples cpus, cuyos marcos de tiempo se pueden dar a múltiples procesos. Eso hace que la programación de tareas sea un poco más compleja, pero no demasiado. Pero la situación es la misma.
El kernel es inteligente, trata de compartir los recursos del sistema para una eficiencia óptima, y está cerca de eso (hay cosas menores de optimización, por ejemplo, es mejor si un proceso se ejecutará el mayor tiempo posible en el mismo CPU debido a consideraciones de almacenamiento en caché, pero no importan allí). Esto se debe a que si tenemos carga 8, eso significa que en realidad hay 8 procesos esperando su próximo segmento de tiempo. Si tenemos 8 cpus, podemos dar estos intervalos de tiempo al cpus uno a uno, y así nuestro sistema se utilizará de manera óptima.
Si ve a top, puede ver que el número de procesos en ejecución reales es sorprendentemente bajo: son los procesos marcados Rallí. Incluso en un sistema no realmente duro, a menudo es inferior a 5. Esto se debe en parte a que los procesos que esperan sus datos de los discos o de la red también están suspendidos (marcados Sen la parte superior). La carga muestra solo el uso de la CPU.
También hay herramientas para medir la carga del disco, en mi opinión, deberían ser al menos importantes como el monitoreo del uso de la CPU, pero de alguna manera no es tan conocido aquí en nuestro mundo profesional de administradores de sistemas.
Las herramientas de Windows a menudo dividen la carga con el número real de cpus. Esto hace que algunos administradores profesionales del sistema de Windows utilicen la carga del sistema en este sentido dividido por CPU. No tienen razón y probablemente estarán más felices después de que les expliques esto.
Las CPU multinúcleo son prácticamente varias CPU en el mismo chip de silicio. No hay diferencia.
En el caso de las CPU hiperprocesadas hay un efecto secundario interesante: cargar una CPU hace que sus pares hiperprocesados sean más lentos. Pero esto sucede en una capa más profunda de lo que maneja la programación normal de tareas, aunque puede (y debería) influir en las decisiones de movimiento del planificador.
Pero desde nuestro punto de vista actual, lo que determina la carga del sistema, tampoco importa.
Como hyperthreading no es en realidad un segundo núcleo, nunca llevará un núcleo al 200%, pero lo llevará más allá del 100% para ciertas cargas de trabajo.
Entonces su carga máxima es desconocida entre 4 y 6
(por supuesto, esto puede aumentar cuando está sobrecargado porque en realidad cuenta los procesos ejecutables, especialmente cuando están esperando IO)
El promedio de carga no significa lo que crees que significa. No se trata del uso instantáneo de la CPU, sino de cuántos procesos están esperando para ejecutarse. Por lo general, eso se debe a muchas cosas que quieren CPU, pero no siempre. Un culpable común es un proceso que espera IO - disco o red.
Intente ejecutar ps -e vy buscar indicadores de estado del proceso.
state The state is given by a sequence of characters, for example, "RWNA". The first character indicates the run state of the process:
D Marks a process in disk (or other short term, uninterruptible) wait.
I Marks a process that is idle (sleeping for longer than about 20 seconds).
L Marks a process that is waiting to acquire a lock.
R Marks a runnable process.
S Marks a process that is sleeping for less than about 20 seconds.
T Marks a stopped process.
W Marks an idle interrupt thread.
Z Marks a dead process (a "zombie").
Esto es de la página de psmanual, por lo que puede encontrar más detalles allí, Ry los Dprocesos son probablemente de particular interés.
Puede terminar con 'picos' promedio de carga por todo tipo de razones, por lo que no son realmente una buena medida de otra cosa que 'este sistema está ocupado'. Atascarse en el promedio de carga de mapeo a los núcleos de la CPU no le servirá de nada.
En un sistema Linux, no solo los procesos en la cola ejecutable se cuentan para calcular la carga, sino también aquellos en estado de suspensión ininterrumpible, wikipedia , lo que hace que la carga aumente cuando tienes muchos procesos esperando el disco.
Hice algunos experimentos en nuestro sistema Xeon de 24 núcleos (2 zócalos x 12 núcleos). La carga máxima es 48.0 en este caso debido a la forma en que Linux configura hyperthreading.
Sin embargo, no obtienes el equivalente a 48 núcleos de rendimiento. Lo que he observado es que obtienes aproximadamente el 90% del rendimiento en los primeros 24 procesadores lógicos, es decir, si la carga se ejecuta a 24.0. Luego obtiene un rendimiento adicional de aproximadamente el 10% para los 24 procesadores lógicos restantes (la carga se ejecuta en 48.0). Otra forma de pensarlo es que si ejecutas 48 hilos en los 24 núcleos, obtendrás un impulso de aproximadamente 10-20% si habilitas el hyperthreading versus no. No es un aumento del 100% como lo implicarían los chicos de marketing.
Por ejemplo, una forma de probar esta observación es tener un proceso que ejecute 48 subprocesos (por ejemplo, usando TBB o modelo de subprocesos manual), luego ejecute
time numactl --physcpubind=0-23 ./myprocess
y luego correr
time numactl --physcpubind=0-47 ./myprocess
Este último debería ejecutarse en aproximadamente 10-20% menos de tiempo. Si su proceso está altamente bloqueado de E / S, entonces el resultado podría ser diferente.
El primero deshabilitará el hyperthreading al permitir que los subprocesos se ejecuten en un único procesador lógico (de cada núcleo), mientras que el segundo habilitará el hyperthreading al permitir que los subprocesos se ejecuten en 2 procesadores lógicos (de cada núcleo).
La carga en ambos casos debe informarse como 48.0 ... lo cual, como puede ver, es muy engañoso.