kernel: vm_thread_new: kstack allocation failed

[Jindrich Fucik]

Ahoj,

Díky za snahu.
Máš podobné úvahy jako já, tedy ty tvoje jsou o dost přesnější.

Já si trochu myslím, že jsem se vydal po nějaké nesprávné cestě.
Prvotní úvaha vycházela z toho, co byla poslední řádka na sériové konzoli (stroj nemá aktivní jinou grafiku, takže jen sériová konzole a pak ssh). Když jsem procházel fóra, tak se hodně mluví o ZFS, ale to není můj případ.

Ale asi to nebyla úplná příčina smrti, hláška regulérně dopadla do /vzr/log/messages a normálně prošla syslogem. Počítač asi zdechnul malou chvilku po této hlášce.

Přidávání paměti a přidávání swap je trochu problém, jedná se o jednodeskový SoIC počítač a tam si člověk něco jen tak nepřidá. Ale naopak všichni okolo mají stejnou konfiguraci, takže je málo pravděpodobné, že bych vymyslel něco exotického. Jediné, co by mohlo být jiné je ten SSD disk, ten je na regulérním drátu, ale zase není moc velký, jen je rozfrcaný na zbytečně velký počet partition.

Počítač ani nemá swap, což je také běžné, protože se často provozuje z SD karty a ta snáší zápisy skutečně špatně.

Dnes periodic proběhl správně a na nic si nestěžuje. Tak to budu ještě nějakou dobu pozorovat.


---------- Původní e-mail ----------
Od: Dan Lukes <dan at obluda.cz>
Komu: FreeBSD mailing list <users-l at freebsd.cz>
Datum: 14. 2. 2019 10:33:39
Předmět: Re: kernel: vm_thread_new: kstack allocation failed
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



-- 
FreeBSD mailing list (users-l at freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l