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.
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
y luego correr
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.
fuente