Blog di Brendan Gregg

Le medie di carico sono una metrica critica del settore-la mia azienda spende milioni di istanze cloud di auto – scaling basate su di esse e altre metriche-ma su Linux c’è qualche mistero intorno a loro. Le medie di carico di Linux tengono traccia non solo delle attività eseguibili, ma anche delle attività nello stato di sospensione ininterrotto. Perché? Non ho mai visto una spiegazione. In questo post risolverò questo mistero e riassumerò le medie di carico come riferimento per tutti coloro che cercano di interpretarle.,

Le medie di carico di Linux sono “medie di carico di sistema” che mostrano la domanda di thread (task) in esecuzione sul sistema come un numero medio di thread in esecuzione più in attesa. Questo misura la domanda, che può essere maggiore di quello che il sistema sta attualmente elaborando. La maggior parte degli strumenti mostra tre medie, per 1, 5 e 15 minuti:

Alcune interpretazioni:

• Se le medie sono 0.0, il sistema è inattivo.
• Se la media di 1 minuto è superiore alla media di 5 o 15 minuti, il carico aumenta.,
• Se la media di 1 minuto è inferiore alle medie di 5 o 15 minuti, il carico diminuisce.
• Se sono superiori al numero di CPU, potresti avere un problema di prestazioni (dipende).

Come un insieme di tre, si può dire se il carico è in aumento o in diminuzione, che è utile. Possono essere utili anche quando si desidera un singolo valore della domanda, ad esempio per una regola di scalabilità automatica del cloud. Ma capirli in modo più dettagliato è difficile senza l’aiuto di altre metriche., Un singolo valore di 23-25, di per sé, non significa nulla, ma potrebbe significare qualcosa se il conteggio della CPU è noto e se è noto per essere un carico di lavoro legato alla CPU.

Invece di provare a eseguire il debug delle medie di carico, di solito passo ad altre metriche. Ne discuterò nella sezione” Better Metrics ” verso la fine.

Cronologia

Le medie di carico originali mostrano solo la domanda della CPU: il numero di processi in esecuzione più quelli in attesa di essere eseguiti., C’è una bella descrizione di questo in RFC 546 intitolato “TENEX Load Averages”, August 1973:

La media del carico TENEX è una misura della domanda di CPU. La media del carico è una media del numero di processi eseguibili in un determinato periodo di tempo. Ad esempio, una media di carico oraria di 10 significherebbe che (per un singolo sistema CPU) in qualsiasi momento durante quell’ora ci si potrebbe aspettare di vedere 1 processo in esecuzione e altri 9 pronti per l’esecuzione (cioè non bloccati per I/O) in attesa della CPU.

La versione di questo su if.,org link a un PDF scansione di un disegnati a mano carico medio grafico da luglio 1973, mostrando che questo è stato monitorato per decenni:

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

al giorno d’Oggi, il codice sorgente per i vecchi sistemi operativi può anche essere trovato on-line. Ecco un’eccezione di DEC macro assembly da TENEX (primi anni 1970) SCHED.MAC:

Ed ecco un estratto da Linux oggi (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 codifica anche le costanti da 1, 5 e 15 minuti.,

Ci sono state metriche medie di carico simili nei sistemi precedenti, tra cui Multics, che avevano una media esponenziale della coda di pianificazione.

I tre numeri

Questi tre numeri sono le medie di carico di 1, 5 e 15 minuti. Tranne che non sono davvero medie, e non sono 1, 5 e 15 minuti. Come si può vedere nella fonte sopra, 1, 5 e 15 minuti sono costanti utilizzate in un’equazione, che calcolano somme mobili esponenzialmente smorzate di una media di cinque secondi. Le medie di carico di 1, 5 e 15 minuti risultanti riflettono il carico ben oltre 1, 5 e 15 minuti.,

Se si prende un sistema inattivo, quindi si inizia un carico di lavoro legato alla CPU a thread singolo (un thread in un ciclo), quale sarebbe la media del carico di un minuto dopo 60 secondi? Se fosse una media normale, sarebbe 1.0. Ecco quell’esperimento, graficamente:

Carica l’esperimento medio per visualizzare lo smorzamento esponenziale

La cosiddetta “media di un minuto” raggiunge solo circa 0,62 per il segno di un minuto. Per ulteriori informazioni sull’equazione e su esperimenti simili, il Dott., Neil Gunther ha scritto un articolo sulle medie di carico: come funziona, in più ci sono molti commenti sui blocchi sorgente Linux in loadavg.c.

Linux Uninterruptible Tasks

Quando le medie di carico sono apparse per la prima volta in Linux, riflettevano la domanda della CPU, come con altri sistemi operativi. Ma in seguito Linux li ha modificati per includere non solo attività eseguibili, ma anche attività nello stato di continuità (TASK_UNINTERRUPTIBLE o nr_uninterruptible). Questo stato viene utilizzato da percorsi di codice che vogliono evitare interruzioni da segnali, che include attività bloccate su disco I / O e alcuni blocchi., Potresti aver visto questo stato prima: si presenta come lo stato” D ” nell’output ps e top. La pagina man di ps(1) lo chiama “sonno ininterrotto (di solito IO)”.

L’aggiunta dello stato di continuità significa che le medie di carico di Linux possono aumentare a causa di un carico di lavoro I / O su disco (o NFS), non solo della domanda di CPU. Per tutti coloro che hanno familiarità con altri sistemi operativi e le loro medie di carico della CPU, compreso questo stato è in un primo momento profondamente confusa.

Perché? Perché, esattamente, Linux ha fatto questo?

Ci sono innumerevoli articoli sulle medie di carico, molti dei quali sottolineano il gotcha Linux nr_uninterruptible., Ma non ho visto nessuno che spieghi o addirittura azzardi un’ipotesi sul motivo per cui è incluso. La mia ipotesi sarebbe stata che ha lo scopo di riflettere la domanda in un senso più generale, piuttosto che solo la domanda della CPU.

Cercare una patch Linux antica

Capire perché qualcosa è cambiato in Linux è facile: leggi la cronologia dei commit di git sul file in questione e leggi la descrizione del cambiamento. Ho controllato la cronologia su loadavg.c, ma la modifica che ha aggiunto lo stato uninterruptible precede quel file, che è stato creato con il codice da un file precedente., Ho controllato l’altro file, ma anche quella traccia ha funzionato a freddo: il codice stesso ha aggirato diversi file. Sperando di prendere una scorciatoia, ho scaricato “git log-p” per l’intero repository github di Linux, che era di 4 Gbyte di testo, e ho iniziato a leggerlo all’indietro per vedere quando il codice è apparso per la prima volta. Anche questo era un vicolo cieco. Il cambiamento più antico nell’intero repository Linux risale al 2005, quando Linus importò Linux 2.6.12-rc2, e questo cambiamento lo precede.

Ci sono repository Linux storici (qui e qui), ma questa descrizione del cambiamento manca anche da quelli., Cercando di scoprire, almeno, quando si è verificato questo cambiamento, ho cercato tarball su kernel.org e ha scoperto che era cambiato da 0.99.15, e non da 0.99.13 – tuttavia, il tarball per 0.99.14 mancava. L’ho trovato altrove e ho confermato che il cambiamento era in Linux 0.99 patchlevel 14, Nov 1993. Speravo che la descrizione del rilascio per 0.99.14 di Linus spiegasse il cambiamento, ma anche questo era un vicolo cieco:

“Le modifiche all’ultima release ufficiale (p13) sono troppo numerose per essere menzionate (o addirittura da ricordare)…,”- Linus

Menziona grandi cambiamenti, ma non la variazione media del carico.

In base alla data, ho cercato gli archivi della mailing list del kernel per trovare la patch effettiva, ma l’email più vecchia disponibile è del giugno 1995, quando l’amministratore di sistema scrive:

“Mentre lavoravo su un sistema per rendere questi archivi di mailing più scalabili Ho accidentalmente distrutto l’attuale set di archivi (ahwhoops).”

La mia ricerca stava iniziando a sentirsi maledetta., Per fortuna, ho trovato alcuni vecchi archivi di mailing list di linux-devel, salvati dai backup del server, spesso archiviati come tarball di digest. Ho cercato oltre 6.000 digest contenenti oltre 98.000 email, 30.000 delle quali risalenti al 1993. Ma in qualche modo mancava a tutti loro. Sembrava davvero come se la descrizione della patch originale potrebbe essere perso per sempre, e il “perché” sarebbe rimasto un mistero.

L’origine di uninterruptible

Fortunatamente, ho finalmente trovato la modifica, in un file di cassetta postale compresso dal 1993 in poi oldlinux.org., Eccolo qui:

È incredibile leggere i pensieri dietro questo cambiamento da quasi 24 anni fa.

Ciò conferma che le medie di carico sono state deliberatamente modificate per riflettere la domanda di altre risorse di sistema, non solo le CPU. Linux è passato da ” medie di carico della CPU “a ciò che si potrebbe chiamare”medie di carico del sistema”.

Il suo esempio di utilizzo di un disco di swap più lento ha senso: degradando le prestazioni del sistema, la domanda sul sistema (misurata come in esecuzione + in coda) dovrebbe aumentare. Tuttavia, le medie di carico sono diminuite perché hanno monitorato solo gli stati di esecuzione della CPU e non gli stati di scambio., Matthias pensava che questo non fosse intuitivo, e lo è, quindi l’ha risolto.

Uninterruptible today

Ma le medie di carico di Linux a volte non sono troppo alte, più di quanto possa essere spiegato dall’I / O del disco? Sì, anche se la mia ipotesi è che ciò sia dovuto a un nuovo percorso di codice che utilizza TASK_UNINTERRUPTIBLE che non esisteva nel 1993. In Linux 0.99.14, c’erano 13 codepath che impostavano direttamente TASK_UNINTERRUPTIBLE o TASK_SWAPPING (lo stato di scambio è stato successivamente rimosso da Linux). Al giorno d’oggi, in Linux 4.12, ci sono quasi 400 codepath che impostano TASK_UNINTERRUPTIBLE, incluse alcune primitive di blocco., È possibile che uno di questi codepath non debba essere incluso nelle medie di carico. La prossima volta che avrò medie di carico che sembrano troppo alte, vedrò se è così e se può essere risolto.

Ho inviato un’email a Matthias (per la prima volta) per chiedere cosa ne pensava del suo cambiamento medio di carico quasi 24 anni dopo. Ha risposto in un’ora (come ho detto su Twitter), e ha scritto:

“Il punto di “carico medio” è quello di arrivare a un numero relativo a quanto sia trafficatoil sistema è da un punto di vista umano. TASK_UNINTERRUPTIBLE means(significato?,) che il processo è in attesa di qualcosa come una lettura del discoche contribuisce al carico del sistema. Un sistema fortemente legato al disco potrebbe essere estremamente lento ma ha solo una media TASK_RUNNING di 0.1, che non aiuta nessuno.”

(Ottenere una risposta così rapidamente, o addirittura una risposta, ha davvero reso la mia giornata. Grazie!)

Quindi Matthias pensa ancora che abbia senso, almeno dato ciò che TASK_UNINTERRUPTIBLE significava.

Ma TASK_UNITERRUPTIBLE corrisponde a più cose oggi. Dovremmo cambiare le medie di carico per essere solo la domanda di CPU e disco?, Il manutentore dello scheduler Peter Zijstra mi ha già inviato un’opzione intelligente da esplorare per farlo: includi task_struct->in_iowait nelle medie di carico invece di TASK_UNINTERRUPTIBLE, in modo che corrisponda più strettamente all’I / O del disco. Vogliamo misurare la domanda sul sistema in termini di thread o semplicemente la domanda di risorse fisiche? Se è il primo, è necessario includere l’attesa dei blocchi di continuità poiché tali thread sono richiesti sul sistema. Non sono inattivi., Quindi forse le medie di carico di Linux funzionano già come vogliamo.

Per comprendere meglio i percorsi di codice ininterrotti, mi piacerebbe un modo per misurarli in azione. Quindi possiamo esaminare diversi esempi, quantificare il tempo trascorso in essi e vedere se tutto ha senso.

Misurazione delle attività di continuità

Quanto segue è un grafico di fiamma off-CPU da un server di produzione, che copre 60 secondi e mostra solo stack del kernel, dove sto filtrando per includere solo quelli nello stato TASK_UNINTERRUPTIBLE (SVG)., Esso fornisce molti esempi di percorsi di codice uninterruptible:

Se siete nuovi a grafici fiamma off-CPU: è possibile fare clic su fotogrammi per ingrandire, esaminando le pile complete che appaiono come una torre di fotogrammi. La dimensione dell’asse X è proporzionale al tempo trascorso dalla CPU bloccata e l’ordinamento (da sinistra a destra) non ha alcun significato reale. Il colore è blu per gli stack off-CPU (uso colori caldi per gli stack on-CPU) e la saturazione ha una varianza casuale per differenziare i frame.,

L’ho generato usando il mio strumento offcputime da bcc (questo strumento ha bisogno di funzionalità eBPF da Linux 4.8+) e il mio software flame graph:

Sto usando awk per cambiare l’output da microsecondi a millisecondi. L’offcputime” state state 2 ” corrisponde a TASK_UNINTERRUPTIBLE (vedi sched.h), ed è un’opzione che ho appena aggiunto per questo post. Josef Bacik di Facebook lo ha fatto per la prima volta con il suo strumento kernelscope, che utilizza anche grafici bcc e flame. Nei miei esempi, sto solo mostrando gli stack del kernel, ma offcputime.py supporta mostrando le pile utente pure.,

Per quanto riguarda il grafico della fiamma sopra: mostra che solo 926 ms su 60 secondi sono stati spesi in uninterruptible sleep. Questo aggiunge solo 0,015 alle nostre medie di carico. È tempo in alcuni percorsi cgroup, ma questo server non sta facendo molto I/O del disco.

Ecco uno più interessante, questa volta solo per 10 secondi (SVG):

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

Questo è il codice di acquisizione del blocco che utilizza TASK_UNINTERRUPTIBLE., Linux ha versioni ininterrotte e interrompibili di mutex acquisiscono funzioni (ad esempio, mutex_lock () vs mutex_lock_interruptible (), e down () e down_interruptible () per i semafori). Le versioni interrompibili consentono di interrompere l’attività da un segnale e quindi di riattivarla per elaborarla prima che il blocco venga acquisito. Il tempo in uninterruptible lock sleeps di solito non aggiunge molto alle medie di carico, ma in questo caso aggiungono 0,30., Se questo fosse molto più alto, varrebbe la pena analizzare per vedere se la contesa di blocco potrebbe essere ridotta (ad esempio, inizierei a scavare su systemd-journal e proc_pid_cmdline_read ()!), che dovrebbe migliorare le prestazioni e abbassare la media del carico.

Ha senso che questi percorsi di codice siano inclusi nella media del carico? Si’, direi di si’. Quei thread sono nel bel mezzo del lavoro e capita di bloccare un lucchetto. Non sono inattivi. Sono richieste sul sistema, anche se per le risorse software piuttosto che per le risorse hardware.,

Scomposizione delle medie di carico Linux

Il valore medio di carico Linux può essere completamente scomposto in componenti? Ecco un esempio: su un sistema di CPU 8 inattivo, ho lanciato tar per archiviare alcuni file non memorizzati. Trascorre diversi minuti per lo più bloccati sulle letture del disco. Ecco le statistiche, raccolte da tre diverse finestre di terminale:

Ho anche raccolto un grafico di fiamma off-CPU solo per lo stato uninterruptible (SVG):

La media di carico finale di un minuto è 1.19. Permettetemi di scomporre che:

• 0.33 proviene dal tempo della CPU di tar (pidstat)
• 0.,67 è dal tar del gruppo di continuità disco di legge, dedotto (offcpu fiamma grafico è questo a 0.69, ho il sospetto che, come ha cominciato a raccogliere un po ‘ più tardi e si estende leggermente diverso intervallo di tempo)
• 0.04 da altre CPU consumatori (iostat utente + sistema, meno tar della CPU da pidstat)
• 0.11 da kernel lavoratori per la continuità del disco I/O tempo, vampate di calore la scrittura su disco (offcpu fiamma grafico, le due torri a sinistra)

Che aggiunge fino a 1.15. Mi manca ancora 0.,04, alcuni dei quali potrebbero essere errori di arrotondamento e offset dell’intervallo di misurazione, ma molto potrebbe essere dovuto al fatto che la media del carico è una somma mobile smorzata esponenzialmente, mentre le altre medie che sto usando (pidstat, iostat) sono medie normali. Prima di 1.19, la media di un minuto era 1.25, quindi alcuni di questi ci trascineranno ancora in alto. Quanto? Dai miei grafici precedenti, al segno di un minuto, il 62% della metrica proveniva da quel minuto, e il resto era più vecchio. Quindi 0,62 x 1,15 + 0,38 x 1,25 = 1,18. Questo è abbastanza vicino al 1.19 riportato.,

Questo è un sistema in cui un thread (tar) più un po ‘di più (un po’ di tempo nei thread di lavoro del kernel) stanno facendo lavoro, e Linux riporta la media del carico come 1.19, il che ha senso. Se misurava le “medie di carico della CPU”, il sistema avrebbe riportato 0.37 (dedotto dal riepilogo di mpstat), che è corretto solo per le risorse della CPU, ma nasconde il fatto che esiste una domanda per oltre un thread di lavoro.

Spero che questo esempio dimostri che i numeri significano davvero qualcosa di deliberato (CPU + uninterruptible), e puoi decomporli e capirlo.,

Dare un senso alle medie di carico di Linux

Sono cresciuto con sistemi operativi in cui le medie di carico significava medie di carico della CPU, quindi la versione Linux mi ha sempre infastidito. Forse il vero problema è che le parole ” medie di carico “sono ambigue quanto”I/O”. Quale tipo di I/O? I / O del disco? I/O del file system? I/O di rete? … Allo stesso modo, quali medie di carico? Medie di carico della CPU? Medie di carico del sistema?, Chiarirlo in questo modo mi permette di dare un senso a questo:

• Su Linux, le medie di carico sono (o cercano di essere) “medie di carico del sistema”, per il sistema nel suo complesso, misurando il numero di thread che funzionano e in attesa di lavorare (CPU, disco, blocchi di continuità). In altre parole, misura il numero di thread che non sono completamente inattivi. Vantaggio: include la domanda di diverse risorse.
• Su altri sistemi operativi, le medie di carico sono “medie di carico della CPU”, che misurano il numero di CPU in esecuzione + thread eseguibili della CPU. Vantaggio: può essere più facile da capire e ragionare (solo per le CPU).,

Si noti che esiste un altro tipo possibile: “medie di carico delle risorse fisiche”, che includerebbe il carico solo per le risorse fisiche (CPU + disco).

Forse un giorno aggiungeremo ulteriori medie di carico a Linux e lasceremo che l’utente scelga ciò che vuole usare: “medie di carico della CPU” separate, “medie di carico del disco”, “medie di carico della rete”, ecc. O semplicemente utilizzare metriche diverse del tutto.

Che cos’è una media di carico “buona” o “cattiva”?,

Alcune persone hanno trovato valori che sembrano funzionare per i loro sistemi e i carichi di lavoro, sanno che quando il carico supera X, applicazione di latenza è alta e i clienti iniziano a lamentarsi. Ma non ci sono davvero regole per questo.

Con le medie di carico della CPU, si potrebbe dividere il valore per il conteggio della CPU, quindi dire che se tale rapporto è superiore a 1.0 si sta eseguendo alla saturazione, il che potrebbe causare problemi di prestazioni., È un po ‘ ambiguo, in quanto è una media a lungo termine (almeno un minuto) che può nascondere la variazione. Un sistema con un rapporto di 1,5 potrebbe funzionare bene, mentre un altro a 1,5 che era bursty entro il minuto potrebbe funzionare male.

Una volta ho amministrato un server di posta elettronica a due CPU che durante il giorno funzionava con una media di carico della CPU compresa tra 11 e 16 (un rapporto tra 5,5 e 8). La latenza era accettabile e nessuno si lamentava. Questo è un esempio estremo: la maggior parte dei sistemi soffrirà con un rapporto carico/CPU di soli 2.,

Per quanto riguarda le medie di carico del sistema di Linux: queste sono ancora più ambigue in quanto coprono diversi tipi di risorse, quindi non puoi semplicemente dividere per il conteggio della CPU. È più utile per i confronti relativi: se sai che il sistema funziona bene con un carico di 20, ed è ora a 40, allora è il momento di scavare con altre metriche per vedere cosa sta succedendo.

Metriche migliori

Quando le medie di carico di Linux aumentano, sai di avere una maggiore domanda di risorse (CPU, dischi e alcuni blocchi), ma non sei sicuro di quale. È possibile utilizzare altre metriche per chiarimenti., Ad esempio, per le CPU:

Le prime due sono metriche di utilizzo, le ultime tre sono metriche di saturazione. Le metriche di utilizzo sono utili per la caratterizzazione del carico di lavoro e le metriche di saturazione sono utili per identificare un problema di prestazioni. Le migliori metriche di saturazione della CPU sono le misure della latenza della coda di esecuzione (o dello scheduler): il tempo in cui un’attività/thread era in uno stato eseguibile, ma doveva attendere il suo turno. Questi consentono di calcolare l’entità di un problema di prestazioni, ad esempio, la percentuale di tempo trascorso da un thread nella latenza dello scheduler., Misurare la lunghezza della coda di esecuzione può invece suggerire che c’è un problema, ma è più difficile stimare la grandezza.

La funzione schedstats è stata resa un kernel sintonizzabile in Linux 4.6 (kernel sysctl.sched_schedstats) e modificato per essere disattivato per impostazione predefinita. Delay accounting espone la stessa metrica di latenza dello scheduler, che è in cpustat e ho appena suggerito di aggiungerla anche a htop, in quanto ciò renderebbe più facile l’uso da parte delle persone., Più facile che, ad esempio, raschiare la metrica wait-time (scheduler latency) dall’output (non documentato) /proc/sched_debug:

Oltre alle metriche della CPU, puoi anche cercare le metriche di utilizzo e saturazione per i dispositivi disco. Mi concentro su tali metriche nel metodo USE e ho una lista di controllo Linux di questi.

Mentre ci sono metriche più esplicite, ciò non significa che le medie di carico siano inutili. Vengono utilizzati con successo nelle politiche di scalabilità per microservizi di cloud computing, insieme ad altre metriche. Questo aiuta microservizi rispondere a diversi tipi di aumenti di carico, CPU o disco I/O., Con queste politiche è più sicuro sbagliare a scalare (costing money) piuttosto che non scalare (costing customers), quindi è auspicabile includere più segnali. Se aumentiamo troppo, eseguiremo il debug del perché il giorno dopo.

L’unica cosa per cui continuo a usare le medie di carico è la loro informazione storica. Se mi viene chiesto di controllare un’istanza con prestazioni scadenti sul cloud, quindi accedere e scoprire che la media di un minuto è molto inferiore alla media di quindici minuti, è un grande indizio che potrei essere troppo tardi per vedere il problema delle prestazioni dal vivo., Ma trascorro solo pochi secondi a contemplare le medie di carico, prima di passare ad altre metriche.

Conclusione

Nel 1993, un ingegnere Linux ha trovato un caso non intuitivo con medie di carico, e con una patch a tre righe li ha cambiati per sempre da “medie di carico della CPU” a ciò che si potrebbe chiamare “medie di carico del sistema.”Il suo cambiamento includeva compiti nello stato di continuità, in modo che le medie di carico riflettessero la domanda di risorse del disco e non solo le CPU., Queste medie di carico del sistema contano il numero di thread che lavorano e in attesa di lavorare e sono riassunte come una tripletta di medie di somma mobile smorzate esponenzialmente che utilizzano 1, 5 e 15 minuti come costanti in un’equazione. Questa tripletta di numeri consente di vedere se il carico è in aumento o in diminuzione, e il loro valore maggiore può essere per i confronti relativi con se stessi.

L’uso dello stato uninterruptible da allora è cresciuto nel kernel Linux, e al giorno d’oggi include uninterruptible lock primitive., Se la media del carico è una misura della domanda in termini di thread in esecuzione e in attesa (e non strettamente thread che desiderano risorse hardware), allora stanno ancora lavorando nel modo in cui vogliamo.

In questo post, ho scavato la patch media del carico Linux del 1993 – che era sorprendentemente difficile da trovare – contenente la spiegazione originale dell’autore. Ho anche misurato le tracce di stack e il tempo nello stato di continuità usando bcc / eBPF su un moderno sistema Linux e visualizzato questa volta come un grafico di fiamma off-CPU., Questa visualizzazione fornisce molti esempi di sonno ininterrotto e può essere generata quando necessario per spiegare medie di carico insolitamente elevate. Ho anche proposto altre metriche che è possibile utilizzare per comprendere il carico del sistema in modo più dettagliato, invece delle medie di carico.

Finirò citando da un commento nella parte superiore di kernel / sched / loadavg.c nel sorgente Linux, dal manutentore dello scheduler Peter Zijlstra:

* Questo file contiene i bit magici necessari per calcolare la figura global loadavg
*. È un numero stupido, ma la gente pensa che sia importante., Passiamo attraverso
* grandi dolori per farlo funzionare su grandi macchine e kernel tickless.

• Saltzer, J. e J. Gintell. ” The Instrumentation of Multics”, CACM, agosto 1970 (spiega gli esponenziali).
• Multics system_performance_graph command reference (menziona la media di 1 minuto).
• Codice sorgente TENEX (il codice medio di carico è in SCHED.MAC).
• RFC 546 “TENEX Load Averages for July 1973” (spiega la misurazione della domanda di CPU).
• Bobrow, D., et al., “TENEX: A Paged Time Sharing System for the PDP-10,” Communications of the ACM, marzo 1972 (spiega la tripletta media del carico).
• Gunther, N. “UNIX Load Average Part 1: How It Works” PDF (spiega i calcoli esponenziali).
• E-mail di Linus su Linux 0.99 patchlevel 14.
• L’e-mail di modifica media del carico è attiva oldlinux.org (in alan-old-funet-lists / kernel.1993.gz, e non nelle directory linux, che ho cercato per primo).
• Il kernel Linux / sched.c fonte prima e dopo la variazione media del carico: 0.99.13, 0.99.14.
• Tarball per Linux 0.,99 versioni sono attive kernel.org.
• Il codice medio di carico Linux corrente: loadavg.c, carico avg.h
• Gli strumenti di analisi ccn includono my offcputime, utilizzato per tracciare TASK_UNINTERRUPTIBLE.
• I grafici di fiamma sono stati utilizzati per visualizzare percorsi di continuità.

Grazie a Deirdre Straughan per le modifiche.