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 <d...@obluda.cz> Komu: FreeBSD mailing list <users-l@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@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
