Dotaz: vysoky load average?

[miro]

Dobry den, mam podla mna celkom vysoky load average

uptime "15:42:56 up 3:19, 7 users, load average: 1,42, 1,57, 1,50"

okolo 1 az 1,5 sa bezne pohybuje od startu systemu, je to normalne? ci treba hladat priciny ? inak system bezi rychlo a stabilne.

CPU i3 2.1 Ghz, 6GB RAM Arch linux, kernel 3.17.6

Odpovědi

[MMMMMMMMM]

iotop? htop? je to server? desktop? 7 uzivatelu asi system trosku vytizi :)

[miro]

je to desktop

[miker@miker-arch ~]$ users miker miker miker miker miker miker miker miker

kde sa tam mohlo vziat tolko userov?

iotop http://pastebin.com/C7BFx35t

mountnuty ntfs disk vykazuje aktivitu

[stativ]

Těch 7 uživatelů spíš budou otevřené konzole.

[TT]

Je to dvou jadro s HT? Tj. to neni zase tak vysoko. Zacal bych se vzrusovat tak pres 2,5 (s HT mozna i load 3 je ok).

[miro]

ano dvojadro s HT

[TT]

Jeste link pro hlubsi pochopeni http://en.wikipedia.org/wiki/Load_%28computing%29#CPU_load_vs_CPU_utilization a pokud to chces rozebirat tak je dobre se podivat i na IO wait

[H0ax]

zažil jsem load 800 (server), pak stroj padnul, zažil jsem load 600 (server), kdy se dalo normálně dělat. Jestli je to stanice, tak load přes 1 je nic.

16:38  up 7 days, 21:23, 3 users, load averages: 1,45 1,55 1,51

to je můj notes

[miro]

tak potom vsetko v poriadku. Ale divne je, ze pod ubuntu mam nizsi average load, a pouzivam tie iste appky, to iste prostredie atd.

miker@miker-K53SC:~$ uptime 16:44:21 up 7 min, 2 users, load average: 0.03, 0.47, 0.36

[Michal Kubeček]

Bez toho, abyste se podíval, co jsou zač ty aktivní procesy a nakolik skutečně zatěžují procesor, nemá smysl snažit se dělat závěry ze samotné hodnoty load average.

[Bill Gates]

Server s loadem 800 nebo 600 se ozval pres konzoli? To teda ziram jak se mu to povedlo. Ja zazil asi 180 max. Odezva trvala vecnost. Jak dlouho jste cekal na odezvu pri tech 800? Se slo vubec prihlasit?

[H0ax]

při těch 800 jsem se přihlásil asi do minuty a mrknul jsem na htop. Něco přes 800 tam bylo a pak to hned umřelo. Těch 600 bylo v klidu, reagovalo to celkem v pohodě, to byl jiný server, myslim nějaký sql only.

[lertimir]

Asi pred 3 lety jsem se staral o server, ktery mel kretkodobe ustat zatez studentu paralelne provadejici kompilace. A pri spoustecich testech paralelne spustena kompilace apache v poctu 100 a 150, ktera simulovala maximalni provozni zatez dostala load pres 300, nicmene server porad prijatelne reagoval.

K tazateli: Tam ocekavam, ze pojede nejaka graficka potvora, witget, plugin v prohlizeci a pod, moc cpu to nevezme ale casto ma svuj proces v R stavu.

[Bill Gates]

A mel jste tam zaply swap? Nebo to byl bezswapovy stroj s dostatecnym mnozstvim ram? Existuje jedna myslenka, nevim jestli dobra nebo spatna, ale me se zda docela dobra, uz jsem to zkusil na jedne VPSce a to mit kotel ram (pricemz stroj ten kotel ram mel opravdu fyzicky) a zadny swap. Jakmile se totiz na brutalne vytizenem serveru lizne o swap tak to je jak slapnout v aute na brzdu a plyn soucasne. Mam pocit ze kdyz je swap vypnuty a narazime na limit ram, tak zajednak uz jak by se melo liznout o swap, tak to je spatne napsana aplikace a v tu chvili kdyz neni swap, zacne fungovat oom killer, zabije ty nejbrutalnejsi procesy a rootovi zbyde prostor pro spravu pres ssh. Tak nejak se to rychleji asi zbrcha ... drive nez kdyz se budou donekonecna presunovat data mezi ram a swapem. Samozrejme do doby nez nam oom killer nekillne ssh, presto mame tak nejak vetsi pravdepodobnost, ze se "dostaneme ke slovu". Co si o tomhle myslite? Ja teda kdyz bylo dost ram a aplikace efektivne napsana z pohledu ram, tak mi to vzdycky slapalo. Pravda o swap jsem ale v tu chvili neliznul, protoze aplikace proste byla dobre napsana a ram bylo porad dost a na swap, ktery byl off, tak nejak nedoslo. Ale myslim ze by to mohlo fakcit v techto extremech .. aspon se s tim strojem proste domluvit.

I kdyz SSD disky ponekud zase meni situaci a server bez SSD dnes - to jako uz nevim, tam to pak asi nehraje roli moc, i kdyz SATA je porad tak nejak to neuzsi hrdlo. Co na to kdo rika?

[Jendа]

Co si o tomhle myslite?

Myslíme si, že je v Linuxu blbě navržený OOM Killer. Swap se může hodit, když máš leakující nebo dlouho neaktivní aplikace, protože to odloží nepoužívané stránky na disk a v paměti zbude víc místa na diskovou cache. Bohužel OOM Killeru nejde říct, aby zabíjel nikoli když dojde paměť i se swapem, ale už když je paměti tak málo, že je potřeba začít swapovat nedávno použité stránky, ale ve swapu je ještě místo.

[Ruža Becelin]

Mame problemy na nekterych serverech s pristupem na SAN, visi to na IO, load pers 4000 a server normalne komunikuje. Ne vzdycky vysoke IO = mrtvy server...

[Jendа]

Extrémní load mohl být způsobený procesy zaseklými v I/O, obsluze hardwaru nebo tak něčeho, ale pokud sshd bylo nacachované v paměti, případně byl root FS na nějakém jiném nezablokovaném zařízení, tak není problém.

[Ivan]

Tezko rict co dneska ten load znamena. Napr. starsi verze Veritas-u pro Linux mely bugu, ze zvysovaly load serveru o jedna za kazde CPU. I kdyz se na severu nic nedelo. Zjednodusene receno, ten driver si vytvoril kernel thread pro kazde CPU a nechal mu nejaky priznak, jako ze to vlakno bezi(muze bezet) i kdyz nic nedelalo. A techle priznaku se pak vypocitaval load systemu.

Takze k tomu, ab mel system vysoky load staci jeden zmateny ovladac a vubec to nemusi souviset s tim co se serverem skutecne deje.

[miro]

z iotopu citam, ze tam vystupuje proces [jbd2/sda---] konkretne sda9 a 8, coz su / a /home a mizne a zobrazuje sa cca kazdych 3 sec a vyuzije IO na nejake cca 2-4%. Myslim, ze tento process bude ten problemovy.

[miro]

pridavam vypis:

[miker@miker-arch ~]$ sudo iotop -obtqqq | grep jbd2 13:40:28 335 be/3 root 0.00 B/s 0.00 B/s 0.00 % 2.09 % [jbd2/sda9-8] 13:40:30 335 be/3 root 0.00 B/s 0.00 B/s 0.00 % 7.34 % [jbd2/sda9-8] 13:40:32 335 be/3 root 0.00 B/s 0.00 B/s 0.00 % 2.08 % [jbd2/sda9-8] 13:40:33 118 be/3 root 0.00 B/s 7.55 K/s 0.00 % 4.02 % [jbd2/sda8-8] 13:40:34 335 be/3 root 0.00 B/s 0.00 B/s 0.00 % 2.10 % [jbd2/sda9-8] 13:40:35 335 be/3 root 0.00 B/s 0.00 B/s 0.00 % 2.11 % [jbd2/sda9-8] 13:40:37 335 be/3 root 0.00 B/s 0.00 B/s 0.00 % 2.13 % [jbd2/sda9-8] 13:40:39 335 be/3 root 0.00 B/s 0.00 B/s 0.00 % 2.14 % [jbd2/sda9-8] 13:40:42 335 be/3 root 0.00 B/s 0.00 B/s 0.00 % 2.15 % [jbd2/sda9-8]

[miro]

osravedlnujem sa za zle vypisany vypis vyssie:

pastebin bude lepsi http://pastebin.com/8Zx1Znde

[miro]

ale ked to porovnam s ubuntu iotop, tak proces jbd2 sa sprava rovnako. Ale celkovy load average je nizsi. Takze asi najlepsie sa tym nezaoberat a byt v tom, ze vsetko je v poriadku. Dakujem za vsetky odpovede.

[nobody]

pokud pises ze v obou pouzivas "tie iste appky" (pochybuju ze i stejne sluzby, ale spis by se dalo cekat ze ubuntu ktere jich pousti vic bude to problematicke:), co zkusit do ubuntu nahodit stejne jadro 3.17.6 jako mas v archu ?

[Sten]

jbd2 je vlákno jádra, které zapisuje (či čistí) žurnál v ext4. Za váš load nemůže.

V htop lze seřadit procesy i podle stavu, pokud není procesor zatížený, tak hledejte ty, které jsou ve stavu D.