Promedios de carga de Linux: resolviendo el misterio

Los promedios de carga son una métrica crítica de la industria: mi empresa gasta millones en escalar automáticamente las instancias de la nube en función de ellas y otras métricas, pero en Linux hay algo de misterio a su alrededor. Los promedios de carga de Linux rastrean no solo las tareas ejecutables, sino también las tareas en estado de suspensión ininterrumpida. ¿Por qué? Nunca he visto una explicación. En este post voy a resolver este misterio, y resumir los promedios de carga como una referencia para todos los que tratan de interpretarlos.,

Los promedios de carga de Linux son «promedios de carga del sistema» que muestran la demanda de subprocesos en ejecución (tareas) en el sistema como un número promedio de subprocesos en ejecución más subprocesos en espera. Esto mide la demanda, que puede ser mayor de lo que el sistema está procesando actualmente. La mayoría de las herramientas muestran tres promedios, para 1, 5 y 15 minutos:

algunas interpretaciones:

Si los promedios son 0.0, entonces su sistema está inactivo.
si el promedio de 1 minuto es mayor que los promedios de 5 o 15 minutos, entonces la carga está aumentando.,
si el promedio de 1 minuto es menor que los promedios de 5 o 15 minutos, entonces la carga está disminuyendo.
si son más altos que el número de CPU, es posible que tenga un problema de rendimiento (depende).

como un conjunto de tres, puede saber si la carga está aumentando o disminuyendo, lo cual es útil. También pueden ser útiles cuando se desea un único valor de demanda, como para una regla de escalado automático en la nube. Pero entenderlos con más detalle es difícil sin la ayuda de otras métricas., Un solo valor de 23-25, por sí mismo, no significa nada, pero podría significar algo si se conoce el recuento de CPU y si se sabe que es una carga de trabajo vinculada a la CPU.

en lugar de intentar depurar los promedios de carga, suelo cambiar a otras métricas. Discutiré esto en la sección» Mejores métricas » cerca del final.

History

Los promedios de carga originales solo muestran la demanda de CPU: el número de procesos en ejecución más los que están esperando para ejecutarse., Hay una buena descripción de esto en el RFC 546 titulado «promedios de carga TENEX», agosto de 1973:

el promedio de carga TENEX es una medida de la demanda de CPU. El promedio de carga es un promedio del número de procesos ejecutables durante un período de tiempo dado. Por ejemplo, un promedio de carga por hora de 10 significaría que (para un solo sistema de CPU) en cualquier momento durante esa hora uno podría esperar ver 1 proceso en ejecución y 9 Otros listos para ejecutarse (es decir, no bloqueados para E/S) esperando la CPU.

la versión de esto en ietf.,org enlaza a un escaneo PDF de un gráfico de promedio de carga dibujado a mano desde julio de 1973, mostrando que esto ha sido monitoreado durante décadas:

fuente: https://tools.ietf.org/html/rfc546

hoy en día, el código fuente de los sistemas operativos antiguos también se puede encontrar en línea. Aquí hay una excepción de Dec macro assembly de TENEX (principios de 1970) SCHED.MAC:

y aquí hay un extracto de Linux today (include/linux/sched / loadavg.h):

#define EXP_1 1884 /* 1/exp(5sec/1min) as fixed-point */#define EXP_5 2014 /* 1/exp(5sec/5min) */#define EXP_15 2037 /* 1/exp(5sec/15min) */

Linux también codifica las constantes de 1, 5 y 15 minutos.,

ha habido métricas de promedio de carga similares en sistemas más antiguos, incluidos Multics, que tenían un promedio de cola de programación exponencial.

los tres números

estos tres números son los promedios de carga de 1, 5 y 15 minutos. Excepto que no son realmente promedios, y no son 1, 5 y 15 minutos. Como se puede ver en la fuente anterior, 1, 5 y 15 minutos son constantes utilizadas en una ecuación, que calculan sumas móviles amortiguadas exponencialmente de un promedio de cinco segundos. Los promedios de carga de 1, 5 y 15 minutos resultantes reflejan la carga mucho más allá de 1, 5 y 15 minutos.,

si toma un sistema inactivo y luego comienza una carga de trabajo vinculada a la CPU de un solo subproceso (un subproceso en un bucle), ¿cuál sería el promedio de carga de un minuto después de 60 segundos? Si fuera un promedio simple, sería 1.0. Aquí está ese experimento, gráficamente:

experimento de carga promedio para visualizar amortiguación exponencial

El llamado» promedio de un minuto » solo alcanza aproximadamente 0.62 por la marca de un minuto. Para más información sobre la ecuación y experimentos similares, el Dr., Neil Gunther ha escrito un artículo sobre los promedios de carga: Cómo funciona, además hay muchos comentarios de bloques de código fuente de Linux en Loadavg.c.

Linux Uninterruptible Tasks

Cuando los promedios de carga aparecieron por primera vez en Linux, reflejaban la demanda de CPU, al igual que con otros sistemas operativos. Pero más tarde Linux los cambió para incluir no solo tareas ejecutables, sino también tareas en estado ininterrumpible (TASK_UNINTERRUPTIBLE o NR_UNINTERRUPTIBLE). Este estado es utilizado por rutas de código que desean evitar interrupciones por Señales, lo que incluye tareas bloqueadas en E/S de disco y algunos bloqueos., Es posible que haya visto este estado antes: se muestra como el estado » D » en la salida ps y top. La página man de ps(1) lo llama «uninterruptible sleep (usualmente IO)».

agregar el estado ininterrumpido significa que los promedios de carga de Linux pueden aumentar debido a una carga de trabajo de E/S de disco (o NFS), no solo a la demanda de CPU. Para todos los familiarizados con otros sistemas operativos y sus promedios de carga de CPU, incluir este estado es al principio profundamente confuso.

¿por Qué? ¿Por qué, exactamente, Linux hizo esto?

Hay innumerables artículos sobre promedios de carga, muchos de los cuales señalan el gotcha Nr_uninterruptible de Linux., Pero no he visto ninguno que explique o incluso arriesgue una conjetura de por qué está incluido. Mi propia conjetura habría sido que está destinado a reflejar la demanda en un sentido más general, en lugar de solo la demanda de CPU.

buscar un antiguo parche de Linux

entender por qué algo cambió en Linux es fácil: lee el historial de cambios de git en el archivo en cuestión y lee la descripción del cambio. Revisé el historial de loadavg.c, pero el cambio que agregó el estado ininterrumpible es anterior a ese archivo, que fue creado con código de un archivo anterior., Revisé el otro archivo, pero ese rastro también se enfrió: el código en sí mismo ha saltado alrededor de diferentes archivos. Con la esperanza de tomar un atajo, tiré «git log-p» para todo el repositorio github de Linux, que era de 4 Gbytes de texto, y comencé a leerlo al revés para ver cuándo apareció el código por primera vez. Esto también era un callejón sin salida. El cambio más antiguo en todo el repositorio de Linux se remonta a 2005, cuando Linus importó Linux 2.6.12-rc2, y este cambio es anterior a eso.

Hay repositorios históricos de Linux (aquí y aquí), pero esta descripción de cambio también falta en ellos., Tratando de descubrir, al menos, cuando se produjo este cambio, busqué tarballs en kernel.org y encontró que había cambiado por 0.99.15, y no por 0.99.13 – sin embargo, el tarball para 0.99.14 faltaba. Lo encontré en otro lugar, y confirmé que el cambio fue en Linux 0.99 patchlevel 14, Nov 1993. Esperaba que la descripción de la versión 0.99.14 de Linus explicara el cambio, pero eso también fue un callejón sin salida:

» los cambios en la última versión oficial (p13) son demasiado numerosos para mencionarlos (o incluso recordarlos)…,»- Linus

menciona cambios importantes, pero no el cambio promedio de carga.

basado en la fecha, busqué los archivos de la lista de correo del núcleo para encontrar el parche real, pero el correo electrónico más antiguo disponible es de junio de 1995, cuando el administrador del sistema escribe:

«mientras trabajaba en un sistema para hacer que estos archivos de correo escalaran más eficazmente destruí accidentalmente el conjunto actual de archivos (ahwhoops).»

mi búsqueda estaba empezando a sentirse maldita., Afortunadamente, encontré algunos archivos antiguos de la lista de correo linux-devel, rescatados de las copias de seguridad del servidor, a menudo almacenados como paquetes de paquetes. Busqué más de 6.000 compendios que contenían más de 98.000 correos electrónicos, 30.000 de los cuales eran de 1993. Pero de alguna manera faltaba en todos ellos. Realmente parecía como si la descripción del parche original se perdiera para siempre, y el «por qué» seguiría siendo un misterio.

El Origen de uninterruptible

afortunadamente, finalmente encontré el cambio, en un archivo de buzón comprimido a partir de 1993 oldlinux.org., Aquí está:

Es increíble leer los pensamientos detrás de este cambio de hace casi 24 años.

esto confirma que los promedios de carga se cambiaron deliberadamente para reflejar la demanda de otros recursos del sistema, no solo de CPU. Linux cambió de » promedios de carga de CPU «a lo que se podría llamar»promedios de carga del sistema».

Su ejemplo de usar un disco swap más lento tiene sentido: al degradar el rendimiento del sistema, la demanda en el sistema (medida como ejecución + cola) debería aumentar. Sin embargo, los promedios de carga disminuyeron porque solo rastreaban los estados de ejecución de la CPU y no los estados de intercambio., Matthias pensó que esto no era intuitivo, y lo es, así que lo arregló.

ininterrumpible hoy

pero no carga Linux promedios a veces ir demasiado alto, más de lo que se puede explicar por e/s de disco? Sí, aunque mi conjetura es que esto se debe a una nueva ruta de código usando TASK_UNINTERRUPTIBLE que no existía en 1993. En Linux 0.99.14, había 13 rutas de código que establecían directamente TASK_UNINTERRUPTIBLE o TASK_SWAPPING (el estado de intercambio fue eliminado más tarde de Linux). Hoy en día, en Linux 4.12, hay casi 400 rutas de código que establecen TASK_UNINTERRUPTIBLE, incluyendo algunas primitivas de bloqueo., Es posible que una de estas rutas de código no se incluya en los promedios de carga. La próxima vez que tenga promedios de carga que parezcan demasiado altos, veré si ese es el caso, y si se puede arreglar.

envié un correo electrónico a Matthias (por primera vez) para preguntarle qué pensaba sobre su cambio promedio de carga casi 24 años después. Respondió en una hora (como mencioné en Twitter), y escribió:

«el punto de «promedio de carga» es llegar a un número relacionado con cómo está el sistema desde un punto de vista humano. TASK_UNINTERRUPTIBLE significa (significa?,) que el proceso está esperando algo así como una lectura de disco que contribuye a la carga del sistema. Un sistema fuertemente enlazado al disco puede ser extremadamente lento, pero solo tiene un promedio TASK_RUNNING de 0.1, lo que no ayuda a nadie.»

(obtener una respuesta tan rápido, o incluso una respuesta en absoluto, realmente me alegró el día. ¡Gracias!)

así que Matthias todavía piensa que tiene sentido, al menos teniendo en cuenta lo que TASK_UNINTERRUPTIBLE solía significar.

pero TASK_UNITERRUPTIBLE coincide con más cosas hoy. ¿Deberíamos cambiar los promedios de carga para que sean solo demanda de CPU y disco?, El mantenedor del planificador Peter Zijstra ya me ha enviado una opción inteligente para explorar para hacer esto: incluir task_struct->in_iowait en promedios de carga en lugar de TASK_UNINTERRUPTIBLE, para que coincida más estrechamente con la E/S del disco. sin embargo, plantea otra pregunta, ¿Qué es lo que realmente queremos? ¿Queremos medir la demanda en el sistema en términos de hilos, o simplemente la demanda de recursos físicos? Si es el primero, entonces se debe incluir la espera de bloqueos ininterrumpidos, ya que esos hilos son de demanda en el sistema. No están ociosos., Así que tal vez los promedios de carga de Linux ya funcionan de la manera que queremos.

para entender mejor las rutas de código ininterrumpidas, me gustaría una forma de medirlas en acción. Entonces podemos examinar diferentes ejemplos, cuantificar el tiempo pasado en ellos, y ver si todo tiene sentido.

midiendo tareas ininterrumpidas

el siguiente es un gráfico de llama fuera de la CPU de un servidor de producción, que abarca 60 segundos y muestra solo las pilas del núcleo, donde estoy filtrando para incluir solo aquellas en el estado TASK_UNINTERRUPTIBLE (SVG)., Proporciona muchos ejemplos de rutas de código ininterrumpidas:

Si es nuevo en los gráficos de llama fuera de la CPU: puede hacer clic en los fotogramas para ampliar, examinando las pilas completas que aparecen como una torre de fotogramas. El tamaño del eje x es proporcional al tiempo que se pasa bloqueado fuera de la CPU, y el orden (de izquierda a derecha) no tiene ningún significado real. El color es azul para las pilas fuera de la CPU (Yo uso colores cálidos para las pilas dentro de la CPU), y la saturación tiene varianza aleatoria para diferenciar fotogramas.,

generé esto usando mi herramienta offcputime de bcc (esta herramienta necesita características eBPF de Linux 4.8+), y mi software flame graph:

estoy usando awk para cambiar la salida de microsegundos a milisegundos. El offcputime «state state 2» coincide con TASK_UNINTERRUPTIBLE (ver sched.h), y es una opción que acabo de añadir para este post. Josef Bacik de Facebook primero hizo esto con su herramienta kernelscope, que también usa gráficos BCC y flame. En mis ejemplos, solo estoy mostrando las pilas del núcleo, pero offcputime.py soporta mostrar las pilas de usuarios también.,

en cuanto al gráfico de llama anterior: muestra que solo 926 ms de 60 segundos se gastaron en sueño ininterrumpido. Eso es solo agregar 0.015 a nuestros promedios de carga. Es el momento en algunas rutas de cgroup, pero este servidor no está haciendo mucha E/S de disco.

Aquí hay una más interesante, esta vez solo abarca 10 segundos (SVG):

 /* wait to be given the lock */ while (true) { set_task_state(tsk, TASK_UNINTERRUPTIBLE); if (!waiter.task) break; schedule(); }

Este es el código de adquisición de bloqueo que utiliza TASK_UNINTERRUPTIBLE., Linux tiene versiones ininterrumpidas e interrumpibles de funciones de adquisición mutex (por ejemplo, mutex_lock () vs mutex_lock_interruptible (), y down() y down_interruptible () para semáforos). Las versiones interrumpibles permiten que la tarea sea interrumpida por una señal, y luego se despierta para procesarla antes de que se adquiera el bloqueo. El tiempo en el bloqueo ininterrumpido duerme generalmente no agrega mucho a los promedios de carga, pero en este caso están agregando 0.30., Si esto fuera mucho más alto, valdría la pena analizar para ver si la contención de bloqueo podría reducirse (por ejemplo, comenzaría a cavar en systemd-journal y proc_pid_cmdline_read()!), lo que debería mejorar el rendimiento y reducir el promedio de carga.

¿Tiene sentido que estas rutas de código se incluyan en el promedio de carga? Sí, yo diría que sí. Esos hilos están en el medio de hacer el trabajo, y pasan a bloquear en una cerradura. No están ociosos. Son la demanda en el sistema, aunque para los recursos de software en lugar de recursos de hardware.,

descomponiendo los promedios de carga de Linux

¿Puede el valor promedio de carga de Linux descomponerse completamente en componentes? Aquí hay un ejemplo: en un sistema de CPU idle 8, lancé tar para archivar algunos archivos sin almacenar. Pasa varios minutos en su mayoría bloqueado en las lecturas del disco. Aquí están las estadísticas, recopiladas de tres ventanas de terminales diferentes:

también recopilé un gráfico de llama fuera de la CPU solo para el estado ininterrumpido (SVG):

el promedio de carga final de un minuto es 1.19. Permítanme descomponer que:

0.33 es del tiempo de CPU de tar (pidstat)
0.,67 es del disco ininterrumpido de Tar lee, inferido (offcpu Flame graph tiene esto en 0.69, sospecho que ya que comenzó a recopilar un poco más tarde y abarca un rango de tiempo ligeramente diferente)
0.04 es de otros consumidores de CPU (usuario iostat + sistema, menos la CPU de Tar de pidstat)
0.11 es de kernel workers uninterruptible disk I/O time, flushing disk writes (offcpu flame graph, las dos torres a la izquierda)

que suma 1.15. Todavía me falta 0.,04, algunos de los cuales pueden ser redondeo y errores de compensación del intervalo de medición, pero muchos pueden deberse a que el promedio de carga es una suma móvil amortiguada exponencialmente, mientras que los otros promedios Que Estoy usando (pidstat, iostat) son promedios normales. Antes de 1.19, el promedio de un minuto era 1.25, por lo que parte de eso todavía nos arrastrará alto. ¿Cuánto? De mis gráficos anteriores, en la marca de un minuto, el 62% de la métrica era de ese minuto, y el resto era más antiguo. Así 0.62 x 1.15 + 0.38 x = 1.25 1.18. Eso está bastante cerca del 1.19 reportado.,

Este es un sistema donde un hilo (tar) más un poco más (algún tiempo en los hilos de trabajo del kernel) están trabajando, y Linux reporta el promedio de carga como 1.19, lo cual tiene sentido. Si estuviera midiendo «promedios de carga de CPU», el sistema habría reportado 0.37 (inferido del resumen de mpstat), que es correcto solo para los recursos de CPU, pero oculta el hecho de que hay demanda de más de un subproceso de trabajo.

espero que este ejemplo muestre que los números realmente significan algo deliberado (CPU + ininterrumpible), y que pueda descomponerlos y averiguarlo.,

dando sentido a los promedios de carga de Linux

crecí con sistemas operativos donde los promedios de carga significaban promedios de carga de CPU, por lo que la versión de Linux siempre me ha molestado. Tal vez el verdadero problema desde el principio es que las palabras «medias de carga» son tan ambiguas como «E/S». ¿Qué tipo de E/S? E/S De Disco? E/s del sistema de archivos? ¿E / S De Red? … Del mismo modo, ¿qué medias de carga? ¿Promedios de carga de CPU? ¿Promedios de carga del sistema?, Aclararlo de esta manera me permite darle sentido de la siguiente manera:

en Linux, los promedios de carga son (o intentan ser) «promedios de carga del sistema», para el sistema en su conjunto, midiendo el número de subprocesos que están funcionando y esperando para funcionar (CPU, disco, bloqueos ininterrumpidos). Dicho de otra manera, mide el número de hilos que no están completamente inactivos. Ventaja: incluye la demanda de diferentes recursos.
en otros sistemas operativos, los promedios de carga son «promedios de carga de CPU», que miden el número de subprocesos ejecutables de CPU + CPU. Ventaja: puede ser más fácil de entender y razonar (solo para CPU).,

tenga en cuenta que hay otro tipo posible: «medias de carga de recursos físicos», que incluiría la carga solo para recursos físicos (CPU + disco).

quizás algún día añadiremos promedios de carga adicionales a Linux, y dejaremos que el usuario elija lo que quiere usar: un «promedios de carga de CPU» separado, «promedios de carga de disco», «promedios de carga de red», etc. O simplemente usa diferentes métricas por completo.

¿qué es un promedio de carga «bueno» o «malo»?,

medias de carga medidas en una herramienta moderna

algunas personas han encontrado valores que parecen funcionar para sus sistemas y cargas de trabajo: saben que cuando la carga pasa por encima de X, la latencia de la aplicación es alta y los clientes comienzan a quejarse. Pero en realidad no hay reglas para esto.

con los promedios de carga de CPU, se podría dividir el valor por el recuento de CPU, y luego decir que si esa relación es superior a 1.0 se está ejecutando en saturación, lo que puede causar problemas de rendimiento., Es algo ambiguo, ya que es un promedio a largo plazo (al menos un minuto) que puede ocultar la variación. Un sistema con una relación de 1.5 podría estar funcionando bien, mientras que otro en 1.5 que estaba lleno en el minuto podría estar funcionando mal.

Una vez administré un servidor de correo electrónico de dos CPU que durante el día funcionó con un promedio de carga de CPU de entre 11 y 16 (una relación de entre 5.5 y 8). La latencia era aceptable y nadie se quejaba. Ese es un ejemplo extremo: la mayoría de los sistemas sufrirán con una relación carga / CPU de solo 2.,

en cuanto a los promedios de carga del sistema Linux: estos son aún más ambiguos, ya que cubren diferentes tipos de recursos, por lo que no se puede dividir por el número de CPU. Es más útil para comparaciones relativas: si sabes que el sistema funciona bien con una carga de 20, y ahora está en 40, entonces es hora de profundizar en otras métricas para ver qué está pasando.

mejores métricas

cuando aumentan los promedios de carga de Linux, sabe que tiene una mayor demanda de recursos (CPU, discos y algunos bloqueos), pero no está seguro de cuáles. Puede utilizar otras métricas para clarificar., Por ejemplo, para CPU:

Las dos primeras son métricas de utilización, las tres últimas son métricas de saturación. Las métricas de utilización son útiles para la caracterización de la carga de trabajo y las métricas de saturación son útiles para identificar un problema de rendimiento. Las mejores métricas de saturación de CPU son las medidas de latencia de la cola de ejecución (o programador): el tiempo que una tarea/hilo estaba en un estado ejecutable, pero tuvo que esperar su turno. Estos le permiten calcular la magnitud de un problema de rendimiento, por ejemplo, el porcentaje de tiempo que un subproceso pasa en la latencia del programador., Medir la longitud de la cola de ejecución en su lugar puede sugerir que hay un problema, pero es más difícil estimar la magnitud.

la instalación schedstats se hizo un kernel sintonizable en Linux 4.6 (kernel sysctl.sched_schedstats) y cambió a Desactivado por defecto. La contabilidad de retardo expone la misma métrica de latencia del programador, que está en cpustat y solo sugerí agregarla a htop también, ya que eso haría que sea más fácil de usar para las personas., Más fácil que, por ejemplo, raspar la métrica de tiempo de espera (latencia del programador) de la salida (indocumentada) /proc/sched_debug:

Además de las métricas de CPU, también puede buscar métricas de utilización y saturación para dispositivos de disco. Me enfoco en tales métricas en el método de uso, y tengo una lista de verificación de Linux de estos.

si bien hay métricas más explícitas, eso no significa que los promedios de carga sean inútiles. Se utilizan con éxito en políticas de ampliación para microservicios de cloud computing, junto con otras métricas. Esto ayuda a los microservicios a responder a diferentes tipos de aumentos de carga, CPU o E/S de disco., Con estas políticas, es más seguro errar en la ampliación (costar dinero) que no escalar (costar a los clientes), por lo que es deseable incluir más señales. Si escalamos demasiado, depuraremos por qué al día siguiente.

la única cosa para la que sigo usando promedios de carga es su información histórica. Si me piden que revise una instancia de mal rendimiento en la nube, luego inicie sesión y encuentre que el promedio de un minuto es mucho más bajo que el promedio de quince minutos, es una gran pista de que podría ser demasiado tarde para ver el problema de rendimiento en vivo., Pero solo paso unos segundos contemplando los promedios de carga, antes de pasar a otras métricas.

conclusión

en 1993, un ingeniero de Linux encontró un caso no intuitivo con promedios de carga, y con un parche de tres líneas los cambió para siempre de «promedios de carga de CPU» a lo que uno podría llamar «promedios de carga del sistema.»Su cambio incluyó tareas en el estado ininterrumpible, de modo que los promedios de carga reflejaban la demanda de recursos de disco y no solo CPU., Estos promedios de carga del sistema cuentan el número de hilos que trabajan y esperan trabajar, y se resumen como un triplete de promedios de suma móvil amortiguados exponencialmente que usan 1, 5 y 15 minutos como constantes en una ecuación. Este triplete de números le permite ver si la carga está aumentando o disminuyendo, y su mayor valor puede ser para comparaciones relativas con ellos mismos.

el uso del estado ininterrumpido ha crecido desde entonces en el núcleo Linux, y hoy en día incluye primitivas de bloqueo ininterrumpido., Si el promedio de carga es una medida de la demanda en términos de subprocesos en ejecución y en espera (y no estrictamente subprocesos que desean recursos de hardware), entonces todavía están funcionando de la manera que queremos que lo hagan.

en este post, desenterré el parche de carga promedio de Linux de 1993 – que fue sorprendentemente difícil de encontrar – que contiene la explicación original del autor. También medí las trazas de pila y el tiempo en el estado ininterrumpible utilizando BCC / eBPF en un sistema Linux moderno, y visualizé esta vez como un gráfico de llama fuera de la CPU., Esta visualización proporciona muchos ejemplos de tiempos de espera ininterrumpidos, y se puede generar siempre que sea necesario para explicar promedios de carga inusualmente altos. También propuse otras métricas que puede usar para comprender la carga del sistema con más detalle, en lugar de los promedios de carga.

terminaré citando un comentario en la parte superior de kernel/sched / loadavg.c En el código fuente de Linux, por el responsable del planificador Peter Zijlstra:

* este archivo contiene los bits mágicos necesarios para calcular la figura global loadavg
*. Es un número tonto pero la gente piensa que es importante., Pasamos por grandes esfuerzos para hacer que funcione en máquinas grandes y núcleos sin cosquillas.

Saltzer, J., and J. Gintell. «The Instrumentation of Multics», CACM, agosto de 1970 (explica los exponenciales).
Multics system_performance_graph command reference (menciona el promedio de 1 minuto).
código fuente TENEX (el código promedio de carga está en SCHED.MAC).
RFC 546 «Tenex Load Averages for July 1973» (explica la medición de la demanda de CPU).
Bobrow, D., et al., «TENEX: a Paged Time Sharing System for the PDP-10,» Communications of the ACM, March 1972 (explains the load average triplet).
Gunther, N.» UNIX Load Average Part 1: How It Works » PDF (explica los cálculos exponenciales).
Correo Electrónico de Linus sobre Linux 0.99 patchlevel 14.
El Correo electrónico de cambio promedio de carga está activado oldlinux.org (en alan-old-funet-lists / kernel.1993.gz, y no en los directorios de linux, que busqué primero).
El kernel de Linux / sched.C fuente antes y después del cambio promedio de carga: 0.99.13, 0.99.14.
Tarballs Para Linux 0.,99 lanzamientos están en kernel.org.
El Código promedio de carga actual de Linux: Loadavg.c, loadavg.h
Las herramientas de análisis de bcc incluyen my offcputime, que se utiliza para rastrear TASK_UNINTERRUPTIBLE.
Se utilizaron gráficos de llama para visualizar rutas ininterrumpidas.

Gracias a Deirdre Straughan por las ediciones.

Blog de Brendan Gregg