mediile de încărcare sunt o valoare critică a industriei-compania mea cheltuiește milioane de instanțe de cloud cu scalare automată pe baza lor și a altor valori – dar pe Linux există un mister în jurul lor. Mediile de încărcare Linux urmăresc nu doar SARCINI rulabile, ci și sarcini în starea de somn neîntreruptibilă. De ce? N-am văzut niciodată o explicație. În acest post voi rezolva acest mister și voi rezuma mediile de încărcare ca referință pentru toată lumea care încearcă să le interpreteze.,
mediile de încărcare Linux sunt „mediile de încărcare a sistemului” care arată cererea de fir de rulare (sarcină) din sistem ca un număr mediu de fire de rulare plus așteptare. Aceasta măsoară cererea, care poate fi mai mare decât ceea ce sistemul procesează în prezent. Cele mai multe instrumente arată trei medii, pentru 1, 5 și 15 minute:
unele interpretări:
- dacă mediile sunt 0,0, atunci sistemul dvs. este inactiv.
- dacă media de 1 minut este mai mare decât mediile de 5 sau 15 minute, atunci încărcarea crește.,
- dacă media de 1 minut este mai mică decât mediile de 5 sau 15 minute, atunci încărcarea scade.
- dacă acestea sunt mai mari decât numărul procesorului dvs., atunci este posibil să aveți o problemă de performanță (depinde).ca un set de trei, puteți spune dacă sarcina este în creștere sau în scădere, ceea ce este util. Ele pot fi, de asemenea, utile atunci când se dorește o singură valoare a cererii, cum ar fi pentru o regulă de scalare automată în cloud. Dar pentru a le înțelege mai detaliat este dificil fără ajutorul altor valori., O singură valoare de 23-25, de la sine, nu înseamnă nimic, dar ar putea însemna ceva dacă Numărul procesorului este cunoscut și dacă se știe că este un volum de muncă legat de CPU.
în loc să încerc să depanez mediile de încărcare, de obicei trec la alte valori. Voi discuta despre acestea în secțiunea” valori mai bune ” aproape de sfârșit.
istoric
mediile de încărcare originale arată doar cererea procesorului: numărul de procese care rulează plus cele care așteaptă să ruleze., Există o descriere frumoasă a acestui lucru în RFC 546 intitulat „mediile de încărcare TENEX”, August 1973:
media de încărcare TENEX este o măsură a cererii procesorului. Media de încărcare este o medie a numărului de procese rulabile într-o anumită perioadă de timp. De exemplu, o medie de încărcare orară de 10 ar însemna că (pentru un singur sistem CPU) în orice moment în acea oră s-ar putea aștepta să vadă 1 proces care rulează și altele 9 gata de rulare (adică nu sunt blocate pentru I/O) așteptând CPU.
Versiunea acestui lucru pe ietf.,org link-uri într-un PDF scanare de o trase de mână de încărcare mediu grafic din iulie 1973, arătând că aceasta a fost monitorizată timp de decenii:
sursa: https://tools.ietf.org/html/rfc546în zilele noastre, codul sursă pentru vechile sisteme de operare, de asemenea, pot fi găsite on-line. Iată o excepție a ansamblului macro DEC de la TENEX (începutul lui 1970) SCHED.MAC:
și aici este un fragment din Linux astăzi (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 este, de asemenea, greu de codificare 1, 5, și 15 minute constante.,
au existat valori medii de încărcare similare în sistemele mai vechi, inclusiv Multics, care au avut o medie de coadă de programare exponențială.aceste trei numere sunt mediile de încărcare de 1, 5 și 15 minute. Cu excepția faptului că nu sunt cu adevărat medii și nu sunt 1, 5 și 15 minute. După cum se poate observa în sursa de mai sus, minutele 1, 5 și 15 sunt constante utilizate într-o ecuație, care calculează sumele Mobile amortizate exponențial ale unei medii de cinci secunde. Mediile de încărcare de 1, 5 și 15 minute rezultate reflectă sarcina cu mult peste 1, 5 și 15 minute.,dacă luați un sistem inactiv, atunci începeți o sarcină de lucru legată de CPU cu un singur filet (un fir într-o buclă), care ar fi media de încărcare de un minut după 60 de secunde? Dacă ar fi o medie simplă, ar fi 1.0. Aici este acel experiment, reprezentate grafic:
Încărcare medie experiment pentru a vizualiza exponențială de amortizareașa-numit „un minut mediu” numai ajunge la aproximativ 0.62 de un minut. Pentru mai multe despre ecuație și experimente similare, Dr., Neil Gunther a scris un articol despre mediile de încărcare: cum funcționează, plus că există multe comentarii bloc sursă Linux în loadavg.C.
SARCINI neîntreruptibile Linux
când mediile de încărcare au apărut pentru prima dată în Linux, acestea reflectau cererea procesorului, ca și în cazul altor sisteme de operare. Dar mai târziu, Linux le-a schimbat pentru a include nu numai sarcini rulabile, ci și sarcini în starea neîntreruptibilă (TASK_UNINTERRUPTIBLE sau nr_uninterruptible). Această stare este utilizată de căile de cod care doresc să evite întreruperile prin semnale, care includ sarcini blocate pe i/o pe disc și unele blocări., Este posibil să fi văzut această stare înainte: apare ca starea „D” în PS de ieșire și de sus. Pagina Man ps(1) o numește „somn neîntreruptibil (de obicei IO)”.
adăugarea stării neîntreruptibile înseamnă că mediile de încărcare Linux pot crește din cauza unui volum de lucru i/O pe disc (sau NFS), nu doar a cererii procesorului. Pentru toți cei familiarizați cu alte sisteme de operare și mediile de încărcare a procesorului, inclusiv această stare este la început profund confuză.
De ce? De ce, mai exact, Linux a făcut acest lucru?
există nenumărate articole despre mediile de încărcare, dintre care multe indică Linux nr_uninterruptible gotcha., Dar nu am văzut nici unul care să explice sau chiar să ghicească de ce este inclus. Presupunerea mea ar fi fost că este menită să reflecte cererea într-un sens mai general, mai degrabă decât doar cererea procesorului.
căutarea unui patch Linux antic
înțelegerea de ce ceva sa schimbat în Linux este ușor: citiți istoricul comiterii git pe fișierul în cauză și citiți descrierea modificării. Am verificat istoricul pe loadavg.c, dar schimbarea care a adăugat starea neîntreruptibilă precede acel fișier, care a fost creat cu cod dintr-un fișier anterior., Am verificat celălalt fișier, dar acel traseu a fugit și la rece: codul în sine a sărit în jurul diferitelor fișiere. În speranța de a lua o scurtătură, am aruncat „git log-p” pentru întregul depozit Linux GitHub, care era de 4 Gbytes de text și am început să-l citesc înapoi pentru a vedea când a apărut codul pentru prima dată. Și asta a fost o fundătură. Cea mai veche schimbare din întregul repo Linux datează din 2005, când Linus a importat Linux 2.6.12-rc2, iar această schimbare precede asta.
există repo-uri Linux istorice (aici și aici), dar această descriere a modificării lipsește și din acestea., Încercarea de a descoperi, cel puțin, când a avut loc această modificare, am cautat pe tar kernel.org și a constatat că acesta s-a schimbat de 0.99.15, și nu de 0.99.13 – cu toate acestea, tar pentru 0.99.14 lipsea. Am găsit-o în altă parte, și a confirmat că schimbarea a fost în Linux 0.99 patchlevel 14, Nov 1993. Am fost în speranța că eliberarea descriere pentru 0.99.14 de Linus ar explica schimbarea, dar care de asemenea, a fost o fundătură:
„Modificări de la ultima versiune oficială (p13) sunt prea numeroase pentru a menționa (sau chiar să-și amintească)…,”- Linus
el menționează schimbări majore, dar nu schimbarea medie de încărcare.
în funcție de data, m-am uitat în sus lista de discuții kernel arhive pentru a găsi patch-uri real, dar mai vechi de e-mail este disponibil din iunie 1995, când sysadmin scrie:
„în Timp ce lucrează la un sistem pentru a face aceste discuții arhivele scară moreeffecitvely din greseala am distrus actualul set de arhive (ahwhoops).”
căutarea mea începea să se simtă blestemată., Din fericire, am găsit câteva arhive mai vechi de listă de corespondență linux-devel, salvate din backup-urile serverului, adesea stocate ca tarballs de digests. Am căutat peste 6.000 de digestii care conțin peste 98.000 de e-mailuri, dintre care 30.000 erau din 1993. Dar lipsea cumva din toate. Părea într-adevăr ca și cum descrierea originală a patch-ului ar putea fi pierdută pentru totdeauna, iar „de ce” ar rămâne un mister.
originea neîntreruptibilă
Din fericire, am găsit în sfârșit schimbarea, într-un fișier de căsuță poștală comprimat din 1993 pe oldlinux.org., Iată:
este uimitor să citiți gândurile din spatele acestei schimbări de acum aproape 24 de ani.acest lucru confirmă faptul că mediile de încărcare au fost modificate în mod deliberat pentru a reflecta cererea pentru alte resurse de sistem, nu doar procesoare. Linux s-a schimbat de la „mediile de încărcare a procesorului” la ceea ce s-ar putea numi „mediile de încărcare a sistemului”.
exemplul său de utilizare a unui disc swap mai lent are sens: prin degradarea performanței sistemului, cererea asupra sistemului (măsurată ca rulare + coadă) ar trebui să crească. Cu toate acestea, mediile de încărcare au scăzut, deoarece au urmărit doar stările de rulare ale procesorului și nu stările de schimbare., Matthias a crezut că acest lucru a fost nonintuitiv, care este, așa că a rezolvat-o.
neîntreruptibil astăzi
dar mediile de încărcare Linux nu merg uneori prea mari, mai mult decât poate fi explicat prin i/o pe disc? Da, deși părerea mea este că acest lucru se datorează unei noi căi de cod folosind TASK_UNINTERRUPTIBLE care nu exista în 1993. În Linux 0.99.14, au fost 13 codepaths că seta direct TASK_UNINTERRUPTIBLE sau TASK_SWAPPING (schimbul de stat a fost ulterior eliminate din Linux). În zilele noastre, în Linux 4.12, există aproape 400 de codepaths care setează TASK_UNINTERRUPTIBLE, inclusiv unele primitive de blocare., Este posibil ca unul dintre aceste codepaths să nu fie inclus în mediile de încărcare. Data viitoare când am medii de încărcare care par prea mari, voi vedea dacă acesta este cazul și dacă poate fi rezolvat.
i-am trimis un e-mail lui Matthias (pentru prima dată) pentru a întreba ce crede despre schimbarea medie a încărcăturii sale aproape 24 de ani mai târziu. El a răspuns într-o oră (așa cum am menționat pe Twitter), și a scris:
„punctul de „încărcare medie” este de a ajunge la un număr legate de cum busythe sistemul este din punct de vedere uman. TASK_UNINTERRUPTIBLE înseamnă (a însemnat?,) că procesul așteaptă ceva ca un disc cititcare contribuie la încărcarea sistemului. Un sistem puternic legat de disc ar putea fiextrem de lent, dar are doar o medie TASK_RUNNING de 0.1, care nu ajută pe nimeni.”
(obtinerea unui raspuns atat de repede, sau chiar un raspuns la toate, a facut cu adevarat ziua mea. Multumesc!deci Matthias încă mai crede că are sens, cel puțin având în vedere ce însemna TASK_UNINTERRUPTIBLE.
dar TASK_UNITERRUPTIBLE se potrivește mai multe lucruri astăzi. Ar trebui să schimbăm mediile de încărcare pentru a fi doar cererea procesorului și a discului?, Scheduler responsabilului de Peter Zijstra mi-a trimis deja o opțiune inteligent pentru a explora pentru a face acest lucru: include task_struct->in_iowait în medii de încărcare în loc de TASK_UNINTERRUPTIBLE, așa că nu mai corespunde îndeaproape disk I/O. Se ridică o altă întrebare, cu toate acestea, care este ceea ce vrem noi de fapt? Vrem să măsurăm cererea pe sistem în termeni de fire, sau doar cererea de resurse fizice? Dacă este prima, atunci ar trebui să fie inclusă așteptarea blocărilor neîntreruptibile, deoarece aceste fire sunt cereri în sistem. Nu sunt inactivi., Deci, poate că mediile de încărcare Linux funcționează deja așa cum vrem noi.pentru a înțelege mai bine căile de cod neîntreruptibile, aș dori o modalitate de a le măsura în acțiune. Apoi putem examina diferite exemple, cuantifica timpul petrecut în ele, și a vedea dacă totul are sens.
măsurarea sarcinilor neîntreruptibile
Următorul este un grafic cu flacără Off-CPU de pe un server de producție, care se întinde pe 60 de secunde și arată doar stive de kernel, unde filtrez pentru a le include doar pe cele din starea TASK_UNINTERRUPTIBLE (SVG)., Acesta oferă multe exemple de căi de cod neîntreruptibile:
Dacă sunteți nou la graficele cu flacără off-CPU: puteți face clic pe cadre pentru a mări, examinând stivele complete care apar ca un turn de cadre. Dimensiunea axei x este proporțională cu timpul petrecut blocat off-CPU, iar ordinea de sortare (de la stânga la dreapta) nu are nici un sens real. Culoarea este albastră pentru stivele off-CPU (folosesc culori calde pentru stivele on-CPU), iar saturația are o variație aleatorie pentru a diferenția cadrele.,
am generat acest lucru cu ajutorul meu offcputime instrument de cca (acest instrument are nevoie de eBPF caracteristici de Linux 4.8+), și flacăra mea grafic software:
eu sunt, folosind awk pentru a schimba ieșirea de la microsecunde la milisecunde. Offcputime „– state 2 ” se potrivește cu TASK_UNINTERRUPTIBLE (vezi sched.h), și este o opțiune am adăugat doar pentru acest post. Josef Bacik de la Facebook a făcut acest lucru pentru prima dată cu instrumentul său kernelscope, care folosește și graficele bcc și flame. În exemplele mele, doar arăt stivele de kernel, dar offcputime.py sprijină arată stive de utilizator, de asemenea.,în ceea ce privește graficul flacării de mai sus: arată că doar 926 ms din 60 de secunde au fost petrecute în somn neîntrerupt. Aceasta adaugă doar 0.015 la mediile de încărcare. E timpul, în unele cgroup căi, dar acest server nu este de a face mult disk I/O.
Aici este una mai interesantă, de data aceasta acoperă doar 10 secunde (SVG):
/* wait to be given the lock */ while (true) { set_task_state(tsk, TASK_UNINTERRUPTIBLE); if (!waiter.task) break; schedule(); }Acest lucru este de blocare de achiziție cod care folosește TASK_UNINTERRUPTIBLE., Linux are neîntreruptibilă și întreruptibilă versiuni de mutex dobândi funcții (de exemplu, mutex_lock() vs mutex_lock_interruptible () și în jos() și down_interruptible() pentru semafoare). Versiunile întreruptibile permit ca sarcina să fie întreruptă de un semnal și apoi să se trezească pentru a o procesa înainte de a fi achiziționată blocarea. Timpul în blocarea neîntreruptibilă doarme, de obicei, nu adaugă mult la mediile de încărcare, dar în acest caz adaugă 0,30., Dacă acest lucru a fost mult mai mare, ar fi în valoare de analiza pentru a vedea daca susținute de blocare ar putea fi reduse (de exemplu, aș începe săpat pe systemd-jurnal și proc_pid_cmdline_read()!), care ar trebui să îmbunătățească performanța și să reducă media de încărcare.
are sens ca aceste căi de cod să fie incluse în media de încărcare? Da, așa aș spune. Aceste fire sunt în mijlocul de a face de lucru, și se întâmplă să blocheze pe un sistem de blocare. Nu sunt inactivi. Acestea sunt cererea pe sistem, deși pentru resurse software, mai degrabă decât resurse hardware.,
descompunerea mediilor de încărcare Linux
poate Valoarea medie de încărcare Linux să fie complet descompusă în componente? Iată un exemplu: pe un sistem inactiv cpu 8, am lansat tar pentru a arhiva unele fișiere neacoperite. Se petrece câteva minute cea mai mare parte blocat pe disc citește. Iată statisticile, colectate din trei ferestre terminale diferite:
am colectat, de asemenea, un grafic cu flacără off-CPU doar pentru starea neîntreruptibilă (SVG):
media finală de încărcare de un minut este 1.19. Permiteți-mi să descompun că:
- 0.33 este din timpul procesorului tar (pidstat)
- 0.,67 din tar e neîntreruptibilă citește disc, dedus (offcpu flacără grafic are la 0.69, banuiesc ca asta a început să colecționeze un pic mai târziu, și se întinde pe o ușor diferite interval de timp)
- 0.04 este din alte CPU consumatorilor (iostat utilizator + sistem, minus tar CPU de pidstat)
- 0.11 este de la kernel lucrătorilor neîntreruptibilă disk I/O dată, înroșirea feței disc scrie (offcpu flacără grafic, cele două turnuri de pe stânga)
Care se adaugă până la 1.15. Încă îmi lipsește 0.,04, dintre care unele pot fi de rotunjire și intervalul de măsurare a compensa erorile, dar o mulțime poate fi din cauza la sarcina medie fiind de o exponențial-amortizată în mișcare sumă, întrucât celelalte medii sunt folosind (pidstat, iostat) sunt mediile normale. Înainte de 1.19, media de un minut a fost 1.25, deci unele dintre acestea ne vor trage în continuare. Cât? Din graficele mele anterioare, la marcajul de un minut, 62% Din metrică era din acel minut, iar restul era mai vechi. Deci 0,62 x 1,15 + 0,38 x 1,25 = 1,18. Asta e destul de aproape de 1.19 raportat.,
acesta este un sistem în care un thread (tar) plus un pic mai mult (ceva timp în fire kernel worker) lucrează, iar Linux raportează media de încărcare ca 1.19, ceea ce are sens. Dacă era de măsurare „CPU medii de încărcare”, sistemul s-ar fi raportat 0.37 (dedus din mpstat rezumat), ceea ce este corect pentru resurse CPU numai, dar ascunde faptul că există o cerere pentru peste un fir de munca.sper că acest exemplu arată că numerele înseamnă într-adevăr ceva deliberat (CPU + neîntreruptibil) și le puteți descompune și le puteți da seama.,
înțelegând mediile de încărcare Linux
am crescut cu sisteme de operare în care mediile de încărcare au însemnat medii de încărcare a procesorului, așa că versiunea Linux m-a deranjat întotdeauna. Poate că adevărata problemă este că cuvintele ” medii de încărcare „sunt la fel de ambigue ca”I/O”. Ce tip de I/O? Disc I / O? Sistem de fișiere I / o? I / O Rețea? … De asemenea, care Medii de încărcare? Medii de încărcare CPU? Mediile de încărcare a sistemului?, Clarificarea în acest fel îmi permite să înțeleg acest lucru astfel:
- pe Linux, mediile de încărcare sunt (sau încearcă să fie) „medii de încărcare a sistemului”, pentru sistemul în ansamblu, măsurând numărul de fire care funcționează și așteaptă să funcționeze (CPU, disc, încuietori neîntreruptibile). Pune diferit, măsoară numărul de fire care nu sunt complet inactive. Avantaj: include cererea de resurse diferite.
- pe alte sisteme de Operare, mediile de încărcare sunt „medii de încărcare CPU”, măsurând numărul de fire de rulare CPU + CPU rulabile. Avantaj: poate fi mai ușor de înțeles și de motiv despre (numai pentru procesoare).,rețineți că există un alt tip posibil: „mediile de încărcare a resurselor fizice”, care ar include încărcarea numai pentru resursele fizice (CPU + disc).
poate că într-o zi vom adăuga medii suplimentare de încărcare la Linux și vom lăsa utilizatorul să aleagă ce vrea să folosească: „medii de încărcare CPU” separate, „medii de încărcare pe disc”, „medii de încărcare în rețea” etc. Sau pur și simplu utilizați diferite valori cu totul.
ce este o medie de încărcare” bună” sau „rea”?,
medii de Încărcare măsurată într-un instrument modern Unii oameni au găsit valori care par să lucreze pentru sistemele lor și volumul de lucru: ei știu că atunci când sarcina depășește X, cerere latenta este mare și clienții încep să plâng. Dar nu există reguli pentru asta.
cu mediile de încărcare a procesorului, s-ar putea împărți valoarea la numărul procesorului, apoi spuneți că, dacă raportul este peste 1.0, executați la saturație, ceea ce poate cauza probleme de performanță., Este oarecum ambiguă, deoarece este o medie pe termen lung (cel puțin un minut) care poate ascunde variația. Un sistem cu un raport de 1.5 S-ar putea să funcționeze bine, în timp ce altul la 1.5 care a fost înțepenit în minut ar putea să funcționeze prost.
am administrat odată un server de e-mail cu două CPU-uri care în timpul zilei a rulat cu o medie de încărcare a procesorului cuprinsă între 11 și 16 (un raport cuprins între 5.5 și 8). Latența a fost acceptabilă și nimeni nu sa plâns. Acesta este un exemplu extrem: majoritatea sistemelor vor suferi cu un raport de încărcare/procesor de doar 2.,
în ceea ce privește mediile de încărcare a sistemului Linux: acestea sunt și mai ambigue, deoarece acoperă diferite tipuri de resurse, deci nu puteți împărți doar după numărul procesorului. Este mai util pentru comparații relative: dacă știți că sistemul funcționează bine la o încărcare de 20, iar acum este la 40, atunci este timpul să săpați cu alte valori pentru a vedea ce se întâmplă.
valori mai bune
când mediile de încărcare Linux cresc, știți că aveți o cerere mai mare de resurse (procesoare, discuri și unele blocări), dar nu sunteți sigur care. Puteți utiliza alte valori pentru clarificare., De exemplu, pentru procesoare:
primele două sunt valori de utilizare, ultimele trei sunt valori de saturație. Valorile de Utilizare sunt utile pentru caracterizarea volumului de muncă și valorile de saturație utile pentru identificarea unei probleme de performanță. Cele mai bune valori de saturație a procesorului sunt măsurile de latență a cozii de rulare (sau a planificatorului): timpul în care o sarcină/fir se afla într-o stare de rulare, dar a trebuit să aștepte rândul său. Acestea vă permit să calculeze amploarea unei probleme de performanță, de exemplu, procentul de timp un fir petrecut în latență scheduler., Măsurarea lungimii cozii de rulare în schimb poate sugera că există o problemă, dar este mai dificil de estimat magnitudinea.
facilitatea schedstats a fost făcută un kernel acordabil în Linux 4.6 (kernel sysctl.sched_schedstats) și schimbat pentru a fi oprit în mod implicit. Întârzierea contabilității expune aceeași metrică de latență a planificatorului, care este în cpustat și tocmai am sugerat să o adaug și la htop, deoarece ar face mai ușor pentru oameni să folosească., Mai ușor decât, să zicem, răzuirea metricii wait-time (scheduler latency) din ieșirea (nedocumentată) /proc/sched_debug:
În afară de valorile procesorului, puteți căuta și valori de utilizare și saturație pentru dispozitivele de disc. Mă concentrez pe astfel de valori în metoda de utilizare și am o listă de verificare Linux a acestora.
deși există valori mai explicite, asta nu înseamnă că mediile de încărcare sunt inutile. Acestea sunt utilizate cu succes în politicile de scalare pentru microservicii de cloud computing, împreună cu alte valori. Acest lucru ajută microserviciile să răspundă la diferite tipuri de creșteri de încărcare, CPU sau disc I / O., Cu aceste politici este mai sigur să greșești la scalare (costă bani) decât să nu crești (costă clienții), deci este de dorit să incluzi mai multe semnale. Dacă mărim prea mult, vom depana de ce a doua zi.
singurul lucru pentru care folosesc mediile de încărcare este informațiile lor istorice. Dacă mi se cere să verific o instanță cu performanțe slabe în cloud, atunci conectați-vă și aflați că media de un minut este mult mai mică decât media de cincisprezece minute, este un indiciu mare că s-ar putea să fie prea târziu pentru a vedea problema performanței în direct., Dar petrec doar câteva secunde contemplând mediile de încărcare, înainte de a apela la alte valori.
Concluzie
În 1993, un Linux inginer găsit un nonintuitive caz cu sarcina medii, si cu o gama de trei patch-uri le-a schimbat pentru totdeauna de la „CPU medii de încărcare” pentru ceea ce s-ar putea numi „sistem de medii de încărcare.”Schimbarea sa a inclus sarcini în starea neîntreruptibilă, astfel încât mediile de încărcare au reflectat cererea de resurse de disc și nu doar procesoare., Aceste medii de încărcare a sistemului numără numărul de fire care funcționează și așteaptă să funcționeze și sunt rezumate ca un triplet de medii de sumă mobilă amortizate exponențial care utilizează 1, 5 și 15 minute ca constante într-o ecuație. Acest triplet de numere vă permite să vedeți dacă sarcina este în creștere sau în scădere, iar cea mai mare valoare a acestora poate fi pentru comparații relative cu ei înșiși.utilizarea stării neîntreruptibile a crescut de atunci în kernel-ul Linux, iar în prezent include primitive de blocare neîntreruptibile., Dacă media de încărcare este o măsură a cererii în ceea ce privește rularea și așteptarea firelor (și nu strict firele care doresc resurse hardware), atunci acestea funcționează în continuare așa cum vrem noi.
în această postare, am dezgropat patch – ul mediu de încărcare Linux din 1993 – care a fost surprinzător de greu de găsit-conținând explicația originală a autorului. De asemenea, am măsurat urmele stivei și timpul în starea neîntreruptibilă folosind bcc/eBPF pe un sistem Linux modern și am vizualizat de data aceasta ca un grafic cu flacără off-CPU., Această vizualizare oferă multe exemple de somn neîntreruptibil și poate fi generată ori de câte ori este necesar pentru a explica mediile de încărcare neobișnuit de mari. De asemenea, am propus alte valori pe care le puteți utiliza pentru a înțelege încărcarea sistemului mai detaliat, în loc de mediile de încărcare.
voi termina citând dintr-un comentariu din partea de sus a kernel/sched / loadavg.c în sursa Linux, de planificatorul responsabil Peter Zijlstra:
* acest fișier conține biți magice necesare pentru a calcula loadavg global
* figura. Este un număr prostesc, dar oamenii cred că este important., Trecem prin
* mari dureri pentru a face să funcționeze pe mașini mari și kernel-uri tickless.- Saltzer, J. și J. Gintell. „The Instrumentation of Multics”, CACM, August 1970 (explains exponentials).
- Multics system_performance_graph comandă de referință (menționează media 1 minut).
- TENEX cod sursă (cod mediu de încărcare este în SCHED.MAC).
- RFC 546 „mediile de încărcare TENEX pentru luna iulie 1973” (explică măsurarea cererii CPU).
- Bobrow, D., și colab., „TENEX: un sistem de partajare a timpului paginat pentru PDP-10”, comunicațiile ACM, martie 1972 (explică tripletul mediu de încărcare).
- Gunther, N.” UNIX Load Average Part 1: Cum funcționează ” PDF (explică calculele exponențiale).
- E-mail Linus despre Linux 0.99 patchlevel 14.
- sarcina medie a schimba e-mail este pe oldlinux.org (în alan-vechi-funet-liste/kernel.1993.gz, și nu în directoarele linux, pe care le-am căutat mai întâi).
- kernel-ul Linux / sched.c sursa înainte și după modificarea medie de încărcare: 0.99.13, 0.99.14.
- Tarballs Pentru Linux 0.,99 de versiuni sunt pe kernel.org.
- actualul Cod mediu de încărcare Linux: loadavg.c, loadavg.h
- instrumentele de analiză bcc includ offcputime-ul meu, utilizat pentru urmărirea TASK_UNINTERRUPTIBLE.
- graficele cu flacără au fost utilizate pentru vizualizarea căilor neîntreruptibile.
datorită Deirdre Straughan pentru editări.
