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
Re: kernel: vm_thread_new: kstack allocation failed
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 Komu: FreeBSD mailing list 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
Re: kernel: vm_thread_new: kstack allocation failed
On 14.2.2019 12:51, Jindrich Fucik wrote: 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. No, to skutecne nebyla - zminena udalost neni "panic" ale prosty error. Funkce vrati nulu. Kdyby se alokace povedla, funkce by incializovala td->td_kstack_obj, td->td_kstack, td->td_kstack_pages a vratila by jednicku. vm_thread_new se vola jen ze dvou mist - z thread_alloc a thread_alloc_stack, obe navratovou hodnotu kontroluji a samy reaguji tim, ze vrati NULL respektive 0. Jeste o uroven vys se dostavame na tri funkce - kthread_add, kern_thr_alloc a fork1 - a i ty vsechny navratovou hodnotu kontroluji a samy vraci ENOMEM, pokud doslo k chybe. Dal uz se ale strom volani rozvetvuje prilis a "rucni hledani" tak k cili nevede. Navic je zde moznost, ze pricina padu s uvedenou hlaskou nesouvisi vubec a kernel spadl ze zcela jinych duvodu. Takze jestli se chces pohnout dal, potrebujes coredump. 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ě. Ty tam ale nemas SD ale SSD. Ani tomu sice neni pocet zapisu jedno, ale preci jen je to vyrazne jinde. Ty bys swap mit mohl. jestli pomuze nevim, ale zkusit se to da. Pomoci by mohl i kdyby tahle pamet swapovatelna nebyla - se swapem se fyzicka pamet uvolni odswapovanim neceho jineho. A swap o velikosti minimalne fyzicke pameti (plus neco malo navic) by navic po padu umoznil vytvoreni coredumpu, ze ktereho by mohlo byt poznat lepe na co to vlastne spadlo. Dnes periodic proběhl správně a na nic si nestěžuje. Tak to budu ještě nějakou dobu pozorovat. Tohle muze mit nahodnou miru "zjeveni". Muze zalezet nejen na tom, co dela proces aktualni, ale i na tom co delal proces predchozi (a jak je to davno). V zasade to znamena, ze se pohybuejs nekde na hrane moznosti - a nekdy to spadne za hranu a nekdy ne. Krome pokusu se zalozenim swapu si muzes zkusit jeste hrat se sysctl vm.kstack_cache_size To se selhane alokace bezprostredne tyka - k hlasce, ktera se ti objevila kod nemuze dojit, pokud je pozadovana velikost pameti dostupna v kstack_cache (to je prave rezerva pro budouci alokace). Vetsi cache by mohla tlak na alokator snizit a situaci zlepsit. A nebo taky ne, protoze bude vic pamet vazane v cache a tim nebude dostupna pro zase jine pozadavky (muze ti to tedy zacit padat na nedostatek jine pameti). A kazdopadne, nevime, jestli se to vubec tyka padu ;-) Dan Feb 13 03:05:00 stroj kernel: vm_thread_new: kstack allocation failed Podle me jde o kernelovy stack, ktery potrebuje kazdy proces. -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
