kernel: vm_thread_new: kstack allocation failed
Dan Lukes
dan at obluda.cz
Thu Feb 14 10:32:26 CET 2019
On 13.2.2019 19:27, Jindrich Fucik wrote:
> Feb 13 03:05:00 stroj kernel: vm_thread_new: kstack allocation failed
>
> Pokud jsem správně pochopil, má to co do činění s kmem a s diskovým bufferem.
To si nemyslim. Podle me jde o kernelovy stack, ktery potrebuje kazdy
proces. Kod kernelu je v pameti jen jednou a je namapovan do adresniho
prostoru kazdeho procesu, ale pro svuj beh samozrejme potrebuje i nejaou
tu pamet, ktera uz musi byt pro kazdy proces samostatna. Tohle je
selhana alokace kerneloveho stacku pri vytvareni (fork) dalsiho procesu.
> Zdechne v čase, kdy se pokouší zaindexovat všechny soubory a poslat noční status.
To se rozjedou "periodic" tasky, a ty vedou k relativne velkemu mnozstvi
procesu.
> Tušíte prosím jak tomu stroji pomoci?
Tentokrat nemam cas hledat z jakeho poolu se tahle pamet alokuje a jake
konkretni duvody mohou vest k tomu, ze se alokace nepovede. Ale
nejpravdepodobnejsi vysvetleni je, ze tam te pameti proste neni dost.
Takze tomu stroji nejspis pomuze pridat pamet. Jestli to na tom ARMu jde.
Nejsem si uplne jisty, jestli je tenhle typ pameti swapovatelny. Pokud
ano, pak by to znamenalo, ze v one chvili uz je plna nejen fyzicka pamet
ale i swap a pomohlo by jeho zvetseni, ledaze uz je na maximu.
Pokud je neswapovatelna a do stroje nejde pridat fyzickou pamet, tak si
myslim, ze to nepujde vyresit jinak, nez nejakym laborovanim okolo toho,
kolik v danou chvili bezi soucasne procesu.
Je tu jeste jedna moznost, ze nedostatek pameti je jen zdanlivy - mozna
pamet chybi v konkretnim poolu, ale dala by se sehnat v jinem - ale
takovy presun obvykle nejakou dobu trva (napriklad, kdyz se bere pamet z
diskovejch bufferu, muze byt potreba nejprve zapsat jejich obsah na
disk). A pamet vracena jednim procesem se taky musi nejprve vycistit,
nez ji muze dostat proces jiny. Problem tak muze byt (i) ve "vysokem
obratu", kdy pameti by mohlo byt dost, ale system ji nestiha "recyklovat
k pouziti". To by se asi dalo nejak vytunit - velikost rezerv a
agresitiva cisteni jsou, mam dojem, konfigurovatelne.
Ano, to, ze ti to shodilo celej stroj je nejspis chyba systemu - ve
skutecnosti samozrejme mel selhat jen ten jeden fork a proces, ktery uz
se nevejde, by se nespustil. Ale to se bavim jen o tom, ze pricina by
mel mit jine (mene vazne) dusledky - samotny zakladni problem to neresi.
Tentokrat jsem analyze opravdu venoval mene casu nez obvykle. Vyhrazuju
si pravo byt naprosto vedle.
Dan
More information about the Users-l
mailing list