Ahojte,
sliboval jsem (vetsinou off-list), ze shnu pak resenici s pameti na vpsAdminOS, tak tady to je :)
Kdyz chce programator dneska z aplikace pracovat s velkym souborem, je docela rozsirenym pristupem, si takovy soubor namapovat do pameti pomoci mmap(2) syscallu.
To zpusobi, ze se soubor ocitne ve virtualnim pametovem prostoru procesu, tj. ten program si pak muze sahat do toho souboru prostym pristupovanim do pameti (nabizi se teda snadny ukladani napr. Cckovych structu do souboru, pristup pres pointerovou aritmetiku, atd.).
Linux cachuje takovy napamovany soubor po strankach, protoze samotnou pamet spravuje po strankach (1 stranka pameti je na x64 velka 4 kB, huge pages jsou potom dalsi extra story na jindy...). Jakmile aplikace chce precist nejaka data, Linux na pozadi, pokud uz to neudelal, pro ta data alokuje stranku fyzicke pameti, aby ta data mela realne, kde sedet, precte je do te stranky z disku (nebo kde ten soubor je) a pak tu stranku namapuje do prislusneho mista virtualniho pametoveho prostoru naseho procesu, ktery ta data cte.
Jadro vede mapovane stranky v evidenci pomoci LRU listu, coz je datova struktura, seznam, ktery se vyznacuje tim, ze vede v evidenci, ktera polozka byla pouzita naposled (tak, ze se meni pri jejim pouziti jeji poradi na zacatek seznamu).
Kdyz vsechno funguje jak ma, v realne fyzicke pameti jsou pouzivana ctena data a jeste nezapsane "pospinene" (dirty) stranky, do kterych se psalo, tj. je u nich naplanovano, aby se co nejrychleji dostaly na disk (pokud teda cely soubor nebyl otevreny s flagem O_SYNC, nebo podobne, co by vynutilo kazdou zmenu zapsat na disk ihned, nez Linux vrati kontrolu aplikaci pri tom zapisu do mapovaneho souboru; to neni tak caste a to je nam ted "jedno").
Zapis je nastesti vyreseny dobre, Linux ma na to mechanismus, kteremu rika "writeback throttle"; kdyz detekuje, ze se zacina RAM plnit vic, nez je zdravo, zacne aplikaci ty zapisujici pristupy adekvatne zpomalovat. Tohle "impedancni prizpusobeni" funguje vcelku dobre, navic funguje dostatecne dobre i pod memory cgroup.
Memory cgroup je mechanismus, kterym omezujeme pridelenou pamet kontejnerum pod Linuxem - je to volitelna sada dalsich pocitadel vyuziti pameti, nad zakladni systemove, plus vydeleni ukazatelu na LRU, writeback a dalsi cache, aby se dalo pekne vest takovehle seznamy stranek v oddelene, mimojine aby bylo jasne, co komu patri, kdyz dojde cas tu pamet jednou odklidit. Ale taky, aby se dalo hlidat maximalni vyuziti pameti na ruzne caches - zdaleka nejen - kvuli prave mapovanym souborum.
Potud vsechno dobre.
To nam tak system nabehne, pospousti se na nem stovka VPSek, vsechny aplikace se krasne rozbehnou, nektere si namapujou soubory, nektere do nich vesele zapisuji data...
System muze bezet klidne mesice bez problemu, vsechno stiha, v pohode. Ty seznamy jsou bezne docela kratke, takze sbirka jadernych threadu "kswapd" je na pozadi pekne stiha prochazet a odklizet, jak se postupne nektere memory cgroupy dostavaji s pameti do uzkych.
Koneckoncu, 4 GB RAM (na jeden kontejner) prelozeno na 4 kB stranky znamena teoretickou maximalni delku jednoho seznamu 1M polozek. To se na 2+ gigahertzovych CPU preci stihne projit rychle, ze.
No a pak se stane, ze po treba dvou mesicich behu systemu najednou zoufaly clen pise, ze mu v kontejneru dochazi pamet, pritom at pocita, jak pocita, nemuze se dopocitat, ze by to zabiraly aplikace - je videt, ze je to tim, ze caches nechteji odcouvavat.
Hm, docela spatenka, jak to mame opravit, kdyz to trva tak dlouho, nez se problem projevi? :-D
Tady nekde bych mel podotknout, ze abych byl schopny to takhle pekne vysvetlit, musel jsem doprojit celou cestu do vyresena, takze ted se to jevi zpetne jako trivka, ale nez jsem prisel na to, z ktere strany ten problem pujde aspon nejak resit...
Kdyz se clovek na takovy trpici system prihlasi, vidi tam zpravidla kswapd0 na 100% a kdyz ma ta masina dva fyzicke CPU, tak tam vidi vetsinou i kswapd1 v tom samem stavu.
V dmesgu jsou videt out of memory hlasky z jednotlivych kontejneru, jak narazeji na neodkliditelne caches a jadro zoufale zabiji stare procesy, aby udelalo misto pro dalsi.
V tech OOM hlaskach je videt pokazde i stack trace, odkud ta OOM udalost z jadra prisla - vetsina z nich byla vyvolana kvuli cteni do mmaped souboru, coz se pozna tak, ze v tom stacku jsou videt funkce pridavajici LRU stranky na seznam te memory cgroupe.
Tak si rikam, hm, to ma preci snadne reseni, nebudeme uctovat mapovanou pamet do memory cgroup clenu, ale nechame ji v root memory cgroup...
Okay, to by mohlo fungovat, ze?
..a zase, kswapd0/1 na 100%...
To uz jsem se zacal seriozneji zajimat, co se to vlastne deje, co delaji tak dlouho a jak to cele funguje, kdyz to neslo smaznout "izy hackem".
Napad to byl dobry, fungoval by, nebyt mensi drobnosti:
kswapd, kdyz odklizeji caches na pozadi, prohledavaji memory cgroupy stylem "dej mi takovou, ktera zere nejvic a tu odklidime, kdyz to nebude stacit, pujdem na dalsi".
Tj. pokud se objevi jedna cgroup, ktera je vetsi a ma toho vzdycky vic k odklizeni, muze se vzdycky kswapd zahojit na ni a k dalsim se ani nedostat.
Jedine, kdy se odklizi pamet uplne primo z te memory cgroupy, je tzv. "direct reclaim", cesta kodu primo v momente, kdy je potreba alokovat - ale v tu chvili neni tolik casu na uklizeni, tak se jadro zas tak nesnazi a nekdy to muze vzdat predcasne a rict, ze pamet nenaslo a vyvola OOM situaci v postizene memory cgroupe.
Hmm... okay, takhle by to neslo, tak zkusme mmaped pamet neuctovat cgroupam vubec a nechme ji v zakladnich systemovych seznamech...
A po trochu zapaseni, bo se v jadre s memory cgroup nepocita, ze by nahodou mmaped pamet nebyla uctovana zadne memory cgroupe, je vyreseno, odchod na parek!
...do chvile, nez tim posleme celou masinu out-of-memory a OOM chyby zacnou prichazet odkudkoliv, ne jen z mmaped readu odzpod z mem-cgroup...
Totiz kdyz byly mmaped soubory uctovany na jeden seznam, ktery neni v memory cgroupe, myslelo si jadro, ze ma hodne volnou ruku v tom, co si muze dovolit nechat nacachovane - ale v tom je potom mensi caveat se ZFS... postupny nahodny random access pattern k datum mmaped souboru nadela z ARC slab caches fragmentovane reseto, jeste kdyz se drzi ty kousky z tech puvodne nactenych dat pri zivote "pripinovanim" na jeden velky seznam, ktery nema duvod couvat, protoze host ma preci vsechnu pamet k dispozici bez limitu :D
No pak a chudaci kswapd, kdyz si s tim bordelem maji nejak poradit a odklidit to, *obzvlast* kdyz jsou jen dva a kdyz pod nima mame (konecne spravne nastavene se spravnym ashiftem) NVMe pole... na te staging node (nyni node1.stg) se tak darilo zaplnit RAM az skoro do mrtva.
Takze co s tim? :)
Snadna reseni dosla, bude potreba odklizet ty seznamy per-limitovana-memory-cgroup.
Na nekolik iteraci jsem nakonec dospel k patchi, ktery spusti per-NUMA-node "ksoftlimd" thready, pro kazdou memory cgroupu, ktera ma nastaveny soft_limit.
Ksoftlimd pak dela presne toto - prochazi seznamy svoji memory cgroupy a drzi si je okolo soft_limitu.
Kswapd maji o praci s memory cgroupama min, pokud je jadro nastavene v rezimu, ze ma ksoftlimd poustet automaticky (da se tez spoustet jen rucne).
My jsme zatim defaultne zvolili soft_limit jako watermark, nad ktery se ma ksoftlimd snazit vic odklizet, nastavujeme ho na 80% pameti kontejneru - ale do budoucna mozna tohle jeste predelam na nejakou vetsi automatiku, podle toho, jak kde se ukazou pripadne nedostatky.
Tedy, vysledna situace je, ze pokud aplikace zerou min, jak 80% pameti, ale je co drzet v RAM jako cache, bude mit kontejner vyuzito okolo tech 80% - bude to videt normalne jako aplikacni pamet a zbytek jako caches. Uz by se nemelo stat, ze vyuziti stoupne az ke 100% kvuli caches a ze dojde k OOM a zabijeni procesu.
Zaverem bych jeste zminil ty patche:
Pokus mmaped soubory nauctovat root mem cgroupe:
https://github.com/vpsfreecz/linux/commit/d42232f89795
Pokus mmaped soubory mem cgroupam neuctovat vubec (popis commitu je blbe a celkove je nedocisteny, nebyl jsem s tim spokojeny a nechtel jsem tim travit vic casu, radsi jsem koumal, co dal, at the time...) ->
https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95
A finalne, aktualne nasazena verze ksoftlimd patche:
https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d
A uplne-uplne zaverem: linux kernel neni advanced black magic. Je to jen strasne velka a nekdy dost neforemna kupa C kodu, ktery potrebuje schopne a ochotne instalatery.
V koncinach memory cgroup + memory managementu je teda hodne, co zlepsovat, a vubec to neni raketova veda... Teda obecne, na kontejnerizace v Linuxu je dost co resit.
Takze kdybyste s tim jadernym vyvojem nekdo chtel pomoct, stavte se na IRC, nebo v Base48 v Brne pokecat, neco vymyslime, bude to zabava, trust me ;)
/snajpa
Poutave vysvetleni, dobra prace diky.
čt 13. 8. 2020 v 13:02 odesílatel Pavel Snajdr snajpa@snajpa.net napsal:
Ahojte,
sliboval jsem (vetsinou off-list), ze shnu pak resenici s pameti na vpsAdminOS, tak tady to je :)
Kdyz chce programator dneska z aplikace pracovat s velkym souborem, je docela rozsirenym pristupem, si takovy soubor namapovat do pameti pomoci mmap(2) syscallu.
To zpusobi, ze se soubor ocitne ve virtualnim pametovem prostoru procesu, tj. ten program si pak muze sahat do toho souboru prostym pristupovanim do pameti (nabizi se teda snadny ukladani napr. Cckovych structu do souboru, pristup pres pointerovou aritmetiku, atd.).
Linux cachuje takovy napamovany soubor po strankach, protoze samotnou pamet spravuje po strankach (1 stranka pameti je na x64 velka 4 kB, huge pages jsou potom dalsi extra story na jindy...). Jakmile aplikace chce precist nejaka data, Linux na pozadi, pokud uz to neudelal, pro ta data alokuje stranku fyzicke pameti, aby ta data mela realne, kde sedet, precte je do te stranky z disku (nebo kde ten soubor je) a pak tu stranku namapuje do prislusneho mista virtualniho pametoveho prostoru naseho procesu, ktery ta data cte.
Jadro vede mapovane stranky v evidenci pomoci LRU listu, coz je datova struktura, seznam, ktery se vyznacuje tim, ze vede v evidenci, ktera polozka byla pouzita naposled (tak, ze se meni pri jejim pouziti jeji poradi na zacatek seznamu).
Kdyz vsechno funguje jak ma, v realne fyzicke pameti jsou pouzivana ctena data a jeste nezapsane "pospinene" (dirty) stranky, do kterych se psalo, tj. je u nich naplanovano, aby se co nejrychleji dostaly na disk (pokud teda cely soubor nebyl otevreny s flagem O_SYNC, nebo podobne, co by vynutilo kazdou zmenu zapsat na disk ihned, nez Linux vrati kontrolu aplikaci pri tom zapisu do mapovaneho souboru; to neni tak caste a to je nam ted "jedno").
Zapis je nastesti vyreseny dobre, Linux ma na to mechanismus, kteremu rika "writeback throttle"; kdyz detekuje, ze se zacina RAM plnit vic, nez je zdravo, zacne aplikaci ty zapisujici pristupy adekvatne zpomalovat. Tohle "impedancni prizpusobeni" funguje vcelku dobre, navic funguje dostatecne dobre i pod memory cgroup.
Memory cgroup je mechanismus, kterym omezujeme pridelenou pamet kontejnerum pod Linuxem - je to volitelna sada dalsich pocitadel vyuziti pameti, nad zakladni systemove, plus vydeleni ukazatelu na LRU, writeback a dalsi cache, aby se dalo pekne vest takovehle seznamy stranek v oddelene, mimojine aby bylo jasne, co komu patri, kdyz dojde cas tu pamet jednou odklidit. Ale taky, aby se dalo hlidat maximalni vyuziti pameti na ruzne caches - zdaleka nejen - kvuli prave mapovanym souborum.
Potud vsechno dobre.
To nam tak system nabehne, pospousti se na nem stovka VPSek, vsechny aplikace se krasne rozbehnou, nektere si namapujou soubory, nektere do nich vesele zapisuji data...
System muze bezet klidne mesice bez problemu, vsechno stiha, v pohode. Ty seznamy jsou bezne docela kratke, takze sbirka jadernych threadu "kswapd" je na pozadi pekne stiha prochazet a odklizet, jak se postupne nektere memory cgroupy dostavaji s pameti do uzkych.
Koneckoncu, 4 GB RAM (na jeden kontejner) prelozeno na 4 kB stranky znamena teoretickou maximalni delku jednoho seznamu 1M polozek. To se na 2+ gigahertzovych CPU preci stihne projit rychle, ze.
No a pak se stane, ze po treba dvou mesicich behu systemu najednou zoufaly clen pise, ze mu v kontejneru dochazi pamet, pritom at pocita, jak pocita, nemuze se dopocitat, ze by to zabiraly aplikace - je videt, ze je to tim, ze caches nechteji odcouvavat.
Hm, docela spatenka, jak to mame opravit, kdyz to trva tak dlouho, nez se problem projevi? :-D
Tady nekde bych mel podotknout, ze abych byl schopny to takhle pekne vysvetlit, musel jsem doprojit celou cestu do vyresena, takze ted se to jevi zpetne jako trivka, ale nez jsem prisel na to, z ktere strany ten problem pujde aspon nejak resit...
Kdyz se clovek na takovy trpici system prihlasi, vidi tam zpravidla kswapd0 na 100% a kdyz ma ta masina dva fyzicke CPU, tak tam vidi vetsinou i kswapd1 v tom samem stavu.
V dmesgu jsou videt out of memory hlasky z jednotlivych kontejneru, jak narazeji na neodkliditelne caches a jadro zoufale zabiji stare procesy, aby udelalo misto pro dalsi.
V tech OOM hlaskach je videt pokazde i stack trace, odkud ta OOM udalost z jadra prisla - vetsina z nich byla vyvolana kvuli cteni do mmaped souboru, coz se pozna tak, ze v tom stacku jsou videt funkce pridavajici LRU stranky na seznam te memory cgroupe.
Tak si rikam, hm, to ma preci snadne reseni, nebudeme uctovat mapovanou pamet do memory cgroup clenu, ale nechame ji v root memory cgroup...
Okay, to by mohlo fungovat, ze?
..a zase, kswapd0/1 na 100%...
To uz jsem se zacal seriozneji zajimat, co se to vlastne deje, co delaji tak dlouho a jak to cele funguje, kdyz to neslo smaznout "izy hackem".
Napad to byl dobry, fungoval by, nebyt mensi drobnosti:
kswapd, kdyz odklizeji caches na pozadi, prohledavaji memory cgroupy stylem "dej mi takovou, ktera zere nejvic a tu odklidime, kdyz to nebude stacit, pujdem na dalsi".
Tj. pokud se objevi jedna cgroup, ktera je vetsi a ma toho vzdycky vic k odklizeni, muze se vzdycky kswapd zahojit na ni a k dalsim se ani nedostat.
Jedine, kdy se odklizi pamet uplne primo z te memory cgroupy, je tzv. "direct reclaim", cesta kodu primo v momente, kdy je potreba alokovat - ale v tu chvili neni tolik casu na uklizeni, tak se jadro zas tak nesnazi a nekdy to muze vzdat predcasne a rict, ze pamet nenaslo a vyvola OOM situaci v postizene memory cgroupe.
Hmm... okay, takhle by to neslo, tak zkusme mmaped pamet neuctovat cgroupam vubec a nechme ji v zakladnich systemovych seznamech...
A po trochu zapaseni, bo se v jadre s memory cgroup nepocita, ze by nahodou mmaped pamet nebyla uctovana zadne memory cgroupe, je vyreseno, odchod na parek!
...do chvile, nez tim posleme celou masinu out-of-memory a OOM chyby zacnou prichazet odkudkoliv, ne jen z mmaped readu odzpod z mem-cgroup...
Totiz kdyz byly mmaped soubory uctovany na jeden seznam, ktery neni v memory cgroupe, myslelo si jadro, ze ma hodne volnou ruku v tom, co si muze dovolit nechat nacachovane - ale v tom je potom mensi caveat se ZFS... postupny nahodny random access pattern k datum mmaped souboru nadela z ARC slab caches fragmentovane reseto, jeste kdyz se drzi ty kousky z tech puvodne nactenych dat pri zivote "pripinovanim" na jeden velky seznam, ktery nema duvod couvat, protoze host ma preci vsechnu pamet k dispozici bez limitu :D
No pak a chudaci kswapd, kdyz si s tim bordelem maji nejak poradit a odklidit to, *obzvlast* kdyz jsou jen dva a kdyz pod nima mame (konecne spravne nastavene se spravnym ashiftem) NVMe pole... na te staging node (nyni node1.stg) se tak darilo zaplnit RAM az skoro do mrtva.
Takze co s tim? :)
Snadna reseni dosla, bude potreba odklizet ty seznamy per-limitovana-memory-cgroup.
Na nekolik iteraci jsem nakonec dospel k patchi, ktery spusti per-NUMA-node "ksoftlimd" thready, pro kazdou memory cgroupu, ktera ma nastaveny soft_limit.
Ksoftlimd pak dela presne toto - prochazi seznamy svoji memory cgroupy a drzi si je okolo soft_limitu.
Kswapd maji o praci s memory cgroupama min, pokud je jadro nastavene v rezimu, ze ma ksoftlimd poustet automaticky (da se tez spoustet jen rucne).
My jsme zatim defaultne zvolili soft_limit jako watermark, nad ktery se ma ksoftlimd snazit vic odklizet, nastavujeme ho na 80% pameti kontejneru - ale do budoucna mozna tohle jeste predelam na nejakou vetsi automatiku, podle toho, jak kde se ukazou pripadne nedostatky.
Tedy, vysledna situace je, ze pokud aplikace zerou min, jak 80% pameti, ale je co drzet v RAM jako cache, bude mit kontejner vyuzito okolo tech 80% - bude to videt normalne jako aplikacni pamet a zbytek jako caches. Uz by se nemelo stat, ze vyuziti stoupne az ke 100% kvuli caches a ze dojde k OOM a zabijeni procesu.
Zaverem bych jeste zminil ty patche:
Pokus mmaped soubory nauctovat root mem cgroupe:
https://github.com/vpsfreecz/linux/commit/d42232f89795
Pokus mmaped soubory mem cgroupam neuctovat vubec (popis commitu je blbe a celkove je nedocisteny, nebyl jsem s tim spokojeny a nechtel jsem tim travit vic casu, radsi jsem koumal, co dal, at the time...) ->
https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95
A finalne, aktualne nasazena verze ksoftlimd patche:
https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d
A uplne-uplne zaverem: linux kernel neni advanced black magic. Je to jen strasne velka a nekdy dost neforemna kupa C kodu, ktery potrebuje schopne a ochotne instalatery.
V koncinach memory cgroup + memory managementu je teda hodne, co zlepsovat, a vubec to neni raketova veda... Teda obecne, na kontejnerizace v Linuxu je dost co resit.
Takze kdybyste s tim jadernym vyvojem nekdo chtel pomoct, stavte se na IRC, nebo v Base48 v Brne pokecat, neco vymyslime, bude to zabava, trust me ;)
/snajpa _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Dobrá práce, máš můj obdiv.
Zeptám se myslíš, že v Proxmoxu narazili na podobný problém? Přeci jen je to LXC & ZFS a cgroups? Určitě jsou tam aplikace, které také používají mmap, ne? Několikrát jsem četl, že hodně lidí mmap doporučuje ideálně pro velké soubory. např. tady https://blog.askesis.pl/post/2019/02/mmap.html https://stackoverflow.com/questions/258091/when-should-i-use-mmap-for-file-a...
Zdenek pripravto
čt 13. 8. 2020 v 14:22 odesílatel Ondrej Beranek rainbof@gmail.com napsal:
Poutave vysvetleni, dobra prace diky.
čt 13. 8. 2020 v 13:02 odesílatel Pavel Snajdr snajpa@snajpa.net napsal:
Ahojte,
sliboval jsem (vetsinou off-list), ze shnu pak resenici s pameti na vpsAdminOS, tak tady to je :)
Kdyz chce programator dneska z aplikace pracovat s velkym souborem, je docela rozsirenym pristupem, si takovy soubor namapovat do pameti pomoci mmap(2) syscallu.
To zpusobi, ze se soubor ocitne ve virtualnim pametovem prostoru procesu, tj. ten program si pak muze sahat do toho souboru prostym pristupovanim do pameti (nabizi se teda snadny ukladani napr. Cckovych structu do souboru, pristup pres pointerovou aritmetiku, atd.).
Linux cachuje takovy napamovany soubor po strankach, protoze samotnou pamet spravuje po strankach (1 stranka pameti je na x64 velka 4 kB, huge pages jsou potom dalsi extra story na jindy...). Jakmile aplikace chce precist nejaka data, Linux na pozadi, pokud uz to neudelal, pro ta data alokuje stranku fyzicke pameti, aby ta data mela realne, kde sedet, precte je do te stranky z disku (nebo kde ten soubor je) a pak tu stranku namapuje do prislusneho mista virtualniho pametoveho prostoru naseho procesu, ktery ta data cte.
Jadro vede mapovane stranky v evidenci pomoci LRU listu, coz je datova struktura, seznam, ktery se vyznacuje tim, ze vede v evidenci, ktera polozka byla pouzita naposled (tak, ze se meni pri jejim pouziti jeji poradi na zacatek seznamu).
Kdyz vsechno funguje jak ma, v realne fyzicke pameti jsou pouzivana ctena data a jeste nezapsane "pospinene" (dirty) stranky, do kterych se psalo, tj. je u nich naplanovano, aby se co nejrychleji dostaly na disk (pokud teda cely soubor nebyl otevreny s flagem O_SYNC, nebo podobne, co by vynutilo kazdou zmenu zapsat na disk ihned, nez Linux vrati kontrolu aplikaci pri tom zapisu do mapovaneho souboru; to neni tak caste a to je nam ted "jedno").
Zapis je nastesti vyreseny dobre, Linux ma na to mechanismus, kteremu rika "writeback throttle"; kdyz detekuje, ze se zacina RAM plnit vic, nez je zdravo, zacne aplikaci ty zapisujici pristupy adekvatne zpomalovat. Tohle "impedancni prizpusobeni" funguje vcelku dobre, navic funguje dostatecne dobre i pod memory cgroup.
Memory cgroup je mechanismus, kterym omezujeme pridelenou pamet kontejnerum pod Linuxem - je to volitelna sada dalsich pocitadel vyuziti pameti, nad zakladni systemove, plus vydeleni ukazatelu na LRU, writeback a dalsi cache, aby se dalo pekne vest takovehle seznamy stranek v oddelene, mimojine aby bylo jasne, co komu patri, kdyz dojde cas tu pamet jednou odklidit. Ale taky, aby se dalo hlidat maximalni vyuziti pameti na ruzne caches - zdaleka nejen - kvuli prave mapovanym souborum.
Potud vsechno dobre.
To nam tak system nabehne, pospousti se na nem stovka VPSek, vsechny aplikace se krasne rozbehnou, nektere si namapujou soubory, nektere do nich vesele zapisuji data...
System muze bezet klidne mesice bez problemu, vsechno stiha, v pohode. Ty seznamy jsou bezne docela kratke, takze sbirka jadernych threadu "kswapd" je na pozadi pekne stiha prochazet a odklizet, jak se postupne nektere memory cgroupy dostavaji s pameti do uzkych.
Koneckoncu, 4 GB RAM (na jeden kontejner) prelozeno na 4 kB stranky znamena teoretickou maximalni delku jednoho seznamu 1M polozek. To se na 2+ gigahertzovych CPU preci stihne projit rychle, ze.
No a pak se stane, ze po treba dvou mesicich behu systemu najednou zoufaly clen pise, ze mu v kontejneru dochazi pamet, pritom at pocita, jak pocita, nemuze se dopocitat, ze by to zabiraly aplikace - je videt, ze je to tim, ze caches nechteji odcouvavat.
Hm, docela spatenka, jak to mame opravit, kdyz to trva tak dlouho, nez se problem projevi? :-D
Tady nekde bych mel podotknout, ze abych byl schopny to takhle pekne vysvetlit, musel jsem doprojit celou cestu do vyresena, takze ted se to jevi zpetne jako trivka, ale nez jsem prisel na to, z ktere strany ten problem pujde aspon nejak resit...
Kdyz se clovek na takovy trpici system prihlasi, vidi tam zpravidla kswapd0 na 100% a kdyz ma ta masina dva fyzicke CPU, tak tam vidi vetsinou i kswapd1 v tom samem stavu.
V dmesgu jsou videt out of memory hlasky z jednotlivych kontejneru, jak narazeji na neodkliditelne caches a jadro zoufale zabiji stare procesy, aby udelalo misto pro dalsi.
V tech OOM hlaskach je videt pokazde i stack trace, odkud ta OOM udalost z jadra prisla - vetsina z nich byla vyvolana kvuli cteni do mmaped souboru, coz se pozna tak, ze v tom stacku jsou videt funkce pridavajici LRU stranky na seznam te memory cgroupe.
Tak si rikam, hm, to ma preci snadne reseni, nebudeme uctovat mapovanou pamet do memory cgroup clenu, ale nechame ji v root memory cgroup...
Okay, to by mohlo fungovat, ze?
..a zase, kswapd0/1 na 100%...
To uz jsem se zacal seriozneji zajimat, co se to vlastne deje, co delaji tak dlouho a jak to cele funguje, kdyz to neslo smaznout "izy hackem".
Napad to byl dobry, fungoval by, nebyt mensi drobnosti:
kswapd, kdyz odklizeji caches na pozadi, prohledavaji memory cgroupy stylem "dej mi takovou, ktera zere nejvic a tu odklidime, kdyz to nebude stacit, pujdem na dalsi".
Tj. pokud se objevi jedna cgroup, ktera je vetsi a ma toho vzdycky vic k odklizeni, muze se vzdycky kswapd zahojit na ni a k dalsim se ani nedostat.
Jedine, kdy se odklizi pamet uplne primo z te memory cgroupy, je tzv. "direct reclaim", cesta kodu primo v momente, kdy je potreba alokovat - ale v tu chvili neni tolik casu na uklizeni, tak se jadro zas tak nesnazi a nekdy to muze vzdat predcasne a rict, ze pamet nenaslo a vyvola OOM situaci v postizene memory cgroupe.
Hmm... okay, takhle by to neslo, tak zkusme mmaped pamet neuctovat cgroupam vubec a nechme ji v zakladnich systemovych seznamech...
A po trochu zapaseni, bo se v jadre s memory cgroup nepocita, ze by nahodou mmaped pamet nebyla uctovana zadne memory cgroupe, je vyreseno, odchod na parek!
...do chvile, nez tim posleme celou masinu out-of-memory a OOM chyby zacnou prichazet odkudkoliv, ne jen z mmaped readu odzpod z mem-cgroup...
Totiz kdyz byly mmaped soubory uctovany na jeden seznam, ktery neni v memory cgroupe, myslelo si jadro, ze ma hodne volnou ruku v tom, co si muze dovolit nechat nacachovane - ale v tom je potom mensi caveat se ZFS... postupny nahodny random access pattern k datum mmaped souboru nadela z ARC slab caches fragmentovane reseto, jeste kdyz se drzi ty kousky z tech puvodne nactenych dat pri zivote "pripinovanim" na jeden velky seznam, ktery nema duvod couvat, protoze host ma preci vsechnu pamet k dispozici bez limitu :D
No pak a chudaci kswapd, kdyz si s tim bordelem maji nejak poradit a odklidit to, *obzvlast* kdyz jsou jen dva a kdyz pod nima mame (konecne spravne nastavene se spravnym ashiftem) NVMe pole... na te staging node (nyni node1.stg) se tak darilo zaplnit RAM az skoro do mrtva.
Takze co s tim? :)
Snadna reseni dosla, bude potreba odklizet ty seznamy per-limitovana-memory-cgroup.
Na nekolik iteraci jsem nakonec dospel k patchi, ktery spusti per-NUMA-node "ksoftlimd" thready, pro kazdou memory cgroupu, ktera ma nastaveny soft_limit.
Ksoftlimd pak dela presne toto - prochazi seznamy svoji memory cgroupy a drzi si je okolo soft_limitu.
Kswapd maji o praci s memory cgroupama min, pokud je jadro nastavene v rezimu, ze ma ksoftlimd poustet automaticky (da se tez spoustet jen rucne).
My jsme zatim defaultne zvolili soft_limit jako watermark, nad ktery se ma ksoftlimd snazit vic odklizet, nastavujeme ho na 80% pameti kontejneru - ale do budoucna mozna tohle jeste predelam na nejakou vetsi automatiku, podle toho, jak kde se ukazou pripadne nedostatky.
Tedy, vysledna situace je, ze pokud aplikace zerou min, jak 80% pameti, ale je co drzet v RAM jako cache, bude mit kontejner vyuzito okolo tech 80% - bude to videt normalne jako aplikacni pamet a zbytek jako caches. Uz by se nemelo stat, ze vyuziti stoupne az ke 100% kvuli caches a ze dojde k OOM a zabijeni procesu.
Zaverem bych jeste zminil ty patche:
Pokus mmaped soubory nauctovat root mem cgroupe:
https://github.com/vpsfreecz/linux/commit/d42232f89795
Pokus mmaped soubory mem cgroupam neuctovat vubec (popis commitu je blbe a celkove je nedocisteny, nebyl jsem s tim spokojeny a nechtel jsem tim travit vic casu, radsi jsem koumal, co dal, at the time...) ->
https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95
A finalne, aktualne nasazena verze ksoftlimd patche:
https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d
A uplne-uplne zaverem: linux kernel neni advanced black magic. Je to jen strasne velka a nekdy dost neforemna kupa C kodu, ktery potrebuje schopne a ochotne instalatery.
V koncinach memory cgroup + memory managementu je teda hodne, co zlepsovat, a vubec to neni raketova veda... Teda obecne, na kontejnerizace v Linuxu je dost co resit.
Takze kdybyste s tim jadernym vyvojem nekdo chtel pomoct, stavte se na IRC, nebo v Base48 v Brne pokecat, neco vymyslime, bude to zabava, trust me ;)
/snajpa _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Pokud vim, tak u Proxmoxu celou tu kontejnerovou cast dost utlumili prave s tim, jak umrelo OpenVZ jadro - ted to proste nemaji, jak navarit lip, nez vsichni ostatni se standardnim Linuxem.
Tj. bude je to trapit :)
Otazka je, kdo vlastne kde ma potrebu na tech serverech i realne neco poustet.
Ve spouste firemnich prostredi se nakoupi hromada HW a pak se z toho nevyuziva realne ani 1%... takze, ono to "v malem" bude vzdycky jak uchodit. Proste prinejhorsim shodis pametove limity uplne, zejo...
Kdyz to ma stejne jenom jednoho admina, nebo jeden adminsky tym, co se o to stara...
/snajpa
On 2020-08-14 07:37, zd nex wrote:
Dobrá práce, máš můj obdiv.
Zeptám se myslíš, že v Proxmoxu narazili na podobný problém?
Přeci jen je to LXC & ZFS a cgroups? Určitě jsou tam aplikace, které také používají mmap, ne? Několikrát jsem četl, že hodně lidí mmap doporučuje ideálně pro velké soubory. např.
tady https://blog.askesis.pl/post/2019/02/mmap.html [5] https://stackoverflow.com/questions/258091/when-should-i-use-mmap-for-file-a... [6]
Zdenek pripravto
čt 13. 8. 2020 v 14:22 odesílatel Ondrej Beranek rainbof@gmail.com napsal:
Poutave vysvetleni, dobra prace diky.
čt 13. 8. 2020 v 13:02 odesílatel Pavel Snajdr snajpa@snajpa.net napsal:
Ahojte,
sliboval jsem (vetsinou off-list), ze shnu pak resenici s pameti na vpsAdminOS, tak tady to je :)
Kdyz chce programator dneska z aplikace pracovat s velkym souborem, je docela rozsirenym pristupem, si takovy soubor namapovat do pameti pomoci mmap(2) syscallu.
To zpusobi, ze se soubor ocitne ve virtualnim pametovem prostoru procesu, tj. ten program si pak muze sahat do toho souboru prostym pristupovanim do pameti (nabizi se teda snadny ukladani napr. Cckovych structu do souboru, pristup pres pointerovou aritmetiku, atd.).
Linux cachuje takovy napamovany soubor po strankach, protoze samotnou pamet spravuje po strankach (1 stranka pameti je na x64 velka 4 kB, huge pages jsou potom dalsi extra story na jindy...). Jakmile aplikace chce precist nejaka data, Linux na pozadi, pokud uz to neudelal, pro ta data alokuje stranku fyzicke pameti, aby ta data mela realne, kde sedet, precte je do te stranky z disku (nebo kde ten soubor je) a pak tu
stranku namapuje do prislusneho mista virtualniho pametoveho prostoru naseho procesu, ktery ta data cte.
Jadro vede mapovane stranky v evidenci pomoci LRU listu, coz je datova struktura, seznam, ktery se vyznacuje tim, ze vede v evidenci, ktera polozka byla pouzita naposled (tak, ze se meni pri jejim pouziti jeji poradi na zacatek seznamu).
Kdyz vsechno funguje jak ma, v realne fyzicke pameti jsou pouzivana ctena data a jeste nezapsane "pospinene" (dirty) stranky, do kterych se psalo, tj. je u nich naplanovano, aby se co nejrychleji dostaly na disk (pokud teda cely soubor nebyl otevreny s flagem O_SYNC, nebo podobne, co by vynutilo kazdou zmenu zapsat na disk ihned, nez Linux vrati kontrolu aplikaci pri tom zapisu do mapovaneho souboru; to neni tak caste a to je nam ted "jedno").
Zapis je nastesti vyreseny dobre, Linux ma na to mechanismus, kteremu rika "writeback throttle"; kdyz detekuje, ze se zacina RAM plnit vic, nez je zdravo, zacne aplikaci ty zapisujici pristupy adekvatne zpomalovat. Tohle "impedancni prizpusobeni" funguje vcelku dobre, navic funguje dostatecne dobre i pod memory cgroup.
Memory cgroup je mechanismus, kterym omezujeme pridelenou pamet kontejnerum pod Linuxem - je to volitelna sada dalsich pocitadel vyuziti pameti, nad zakladni systemove, plus vydeleni ukazatelu na LRU, writeback a dalsi cache, aby se dalo pekne vest takovehle seznamy
stranek v oddelene, mimojine aby bylo jasne, co komu patri, kdyz dojde cas tu pamet jednou odklidit. Ale taky, aby se dalo hlidat maximalni vyuziti pameti na ruzne caches - zdaleka nejen - kvuli prave mapovanym souborum.
Potud vsechno dobre.
To nam tak system nabehne, pospousti se na nem stovka VPSek, vsechny aplikace se krasne rozbehnou, nektere si namapujou soubory, nektere do nich vesele zapisuji data...
System muze bezet klidne mesice bez problemu, vsechno stiha, v pohode. Ty seznamy jsou bezne docela kratke, takze sbirka jadernych threadu "kswapd" je na pozadi pekne stiha prochazet a odklizet, jak se postupne nektere memory cgroupy dostavaji s pameti do uzkych.
Koneckoncu, 4 GB RAM (na jeden kontejner) prelozeno na 4 kB stranky znamena teoretickou maximalni delku jednoho seznamu 1M polozek. To se na 2+ gigahertzovych CPU preci stihne projit rychle, ze.
No a pak se stane, ze po treba dvou mesicich behu systemu najednou zoufaly clen pise, ze mu v kontejneru dochazi pamet, pritom at pocita, jak pocita, nemuze se dopocitat, ze by to zabiraly aplikace - je videt, ze je to tim, ze caches nechteji odcouvavat.
Hm, docela spatenka, jak to mame opravit, kdyz to trva tak dlouho, nez se problem projevi? :-D
Tady nekde bych mel podotknout, ze abych byl schopny to takhle pekne vysvetlit, musel jsem doprojit celou cestu do vyresena, takze ted se to jevi zpetne jako trivka, ale nez jsem prisel na to, z ktere strany ten problem pujde aspon nejak resit...
Kdyz se clovek na takovy trpici system prihlasi, vidi tam zpravidla kswapd0 na 100% a kdyz ma ta masina dva fyzicke CPU, tak tam vidi
vetsinou i kswapd1 v tom samem stavu.
V dmesgu jsou videt out of memory hlasky z jednotlivych kontejneru, jak narazeji na neodkliditelne caches a jadro zoufale zabiji stare procesy, aby udelalo misto pro dalsi.
V tech OOM hlaskach je videt pokazde i stack trace, odkud ta OOM udalost z jadra prisla - vetsina z nich byla vyvolana kvuli cteni do mmaped souboru, coz se pozna tak, ze v tom stacku jsou videt funkce pridavajici LRU stranky na seznam te memory cgroupe.
Tak si rikam, hm, to ma preci snadne reseni, nebudeme uctovat mapovanou pamet do memory cgroup clenu, ale nechame ji v root memory cgroup...
Okay, to by mohlo fungovat, ze?
..a zase, kswapd0/1 na 100%...
To uz jsem se zacal seriozneji zajimat, co se to vlastne deje, co delaji tak dlouho a jak to cele funguje, kdyz to neslo smaznout "izy hackem".
Napad to byl dobry, fungoval by, nebyt mensi drobnosti:
kswapd, kdyz odklizeji caches na pozadi, prohledavaji memory cgroupy stylem "dej mi takovou, ktera zere nejvic a tu odklidime, kdyz to nebude stacit, pujdem na dalsi".
Tj. pokud se objevi jedna cgroup, ktera je vetsi a ma toho vzdycky vic k odklizeni, muze se vzdycky kswapd zahojit na ni a k dalsim se ani
nedostat.
Jedine, kdy se odklizi pamet uplne primo z te memory cgroupy, je tzv. "direct reclaim", cesta kodu primo v momente, kdy je potreba alokovat - ale v tu chvili neni tolik casu na uklizeni, tak se jadro zas tak
nesnazi a nekdy to muze vzdat predcasne a rict, ze pamet nenaslo a vyvola OOM situaci v postizene memory cgroupe.
Hmm... okay, takhle by to neslo, tak zkusme mmaped pamet neuctovat cgroupam vubec a nechme ji v zakladnich systemovych seznamech...
A po trochu zapaseni, bo se v jadre s memory cgroup nepocita, ze by nahodou mmaped pamet nebyla uctovana zadne memory cgroupe, je vyreseno, odchod na parek!
...do chvile, nez tim posleme celou masinu out-of-memory a OOM chyby zacnou prichazet odkudkoliv, ne jen z mmaped readu odzpod z mem-cgroup...
Totiz kdyz byly mmaped soubory uctovany na jeden seznam, ktery neni v memory cgroupe, myslelo si jadro, ze ma hodne volnou ruku v tom, co si muze dovolit nechat nacachovane - ale v tom je potom mensi caveat se ZFS... postupny nahodny random access pattern k datum mmaped souboru nadela z ARC slab caches fragmentovane reseto, jeste kdyz se drzi ty kousky z tech puvodne nactenych dat pri zivote "pripinovanim" na jeden velky seznam, ktery nema duvod couvat, protoze host ma preci vsechnu pamet k dispozici bez limitu :D
No pak a chudaci kswapd, kdyz si s tim bordelem maji nejak poradit a odklidit to, *obzvlast* kdyz jsou jen dva a kdyz pod nima mame (konecne spravne nastavene se spravnym ashiftem) NVMe pole... na te staging node (nyni node1.stg) se tak darilo zaplnit RAM az skoro do mrtva.
Takze co s tim? :)
Snadna reseni dosla, bude potreba odklizet ty seznamy per-limitovana-memory-cgroup.
Na nekolik iteraci jsem nakonec dospel k patchi, ktery spusti per-NUMA-node "ksoftlimd" thready, pro kazdou memory cgroupu, ktera ma nastaveny soft_limit.
Ksoftlimd pak dela presne toto - prochazi seznamy svoji memory cgroupy a drzi si je okolo soft_limitu.
Kswapd maji o praci s memory cgroupama min, pokud je jadro nastavene v rezimu, ze ma ksoftlimd poustet automaticky (da se tez spoustet jen rucne).
My jsme zatim defaultne zvolili soft_limit jako watermark, nad ktery se ma ksoftlimd snazit vic odklizet, nastavujeme ho na 80% pameti kontejneru - ale do budoucna mozna tohle jeste predelam na nejakou vetsi automatiku, podle toho, jak kde se ukazou pripadne nedostatky.
Tedy, vysledna situace je, ze pokud aplikace zerou min, jak 80% pameti, ale je co drzet v RAM jako cache, bude mit kontejner vyuzito okolo tech 80% - bude to videt normalne jako aplikacni pamet a zbytek jako caches. Uz by se nemelo stat, ze vyuziti stoupne az ke 100% kvuli caches a ze dojde k OOM a zabijeni procesu.
Zaverem bych jeste zminil ty patche:
Pokus mmaped soubory nauctovat root mem cgroupe:
https://github.com/vpsfreecz/linux/commit/d42232f89795 [1]
Pokus mmaped soubory mem cgroupam neuctovat vubec (popis commitu je blbe a celkove je nedocisteny, nebyl jsem s tim spokojeny a nechtel jsem tim travit vic casu, radsi jsem koumal, co dal, at the time...) ->
https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95 [2]
A finalne, aktualne nasazena verze ksoftlimd patche:
https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d [3]
A uplne-uplne zaverem: linux kernel neni advanced black magic. Je to jen strasne velka a nekdy dost neforemna kupa C kodu, ktery potrebuje
schopne a ochotne instalatery.
V koncinach memory cgroup + memory managementu je teda hodne, co zlepsovat, a vubec to neni raketova veda... Teda obecne, na kontejnerizace v Linuxu je dost co resit.
Takze kdybyste s tim jadernym vyvojem nekdo chtel pomoct, stavte se na IRC, nebo v Base48 v Brne pokecat, neco vymyslime, bude to zabava, trust me ;)
/snajpa _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [4]
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [4]
Links:
[1] https://github.com/vpsfreecz/linux/commit/d42232f89795 [2] https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95 [3] https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d [4] http://lists.vpsfree.cz/listinfo/community-list [5] https://blog.askesis.pl/post/2019/02/mmap.html [6] https://stackoverflow.com/questions/258091/when-should-i-use-mmap-for-file-a...
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Cus,
me to u jednoho klienta taky trapi, narazime presne na to co cca popisujes. Zejmena u DEV stroju, kde se to dost toci a zaroven je tam dost velky overcommit na vsech prostredkach. A ano, taky se to deje nekdy od tak 60 do 120dne uptime, pak uz to vetsinou nevydrzime a otocime :-)
Nicmene tenhle problem v LXC je tak 2+roky a trapi nas to teda na LXC & BTRFS & cgroups.
--
Petr Zitny
Dne 14.08.2020 v 9:12 Pavel Snajdr napsal(a):
Pokud vim, tak u Proxmoxu celou tu kontejnerovou cast dost utlumili prave s tim, jak umrelo OpenVZ jadro - ted to proste nemaji, jak navarit lip, nez vsichni ostatni se standardnim Linuxem.
Tj. bude je to trapit :)
Otazka je, kdo vlastne kde ma potrebu na tech serverech i realne neco poustet.
Ve spouste firemnich prostredi se nakoupi hromada HW a pak se z toho nevyuziva realne ani 1%... takze, ono to "v malem" bude vzdycky jak uchodit. Proste prinejhorsim shodis pametove limity uplne, zejo...
Kdyz to ma stejne jenom jednoho admina, nebo jeden adminsky tym, co se o to stara...
/snajpa
On 2020-08-14 07:37, zd nex wrote:
Dobrá práce, máš můj obdiv.
Zeptám se myslíš, že v Proxmoxu narazili na podobný problém?
Přeci jen je to LXC & ZFS a cgroups? Určitě jsou tam aplikace, které také používají mmap, ne? Několikrát jsem četl, že hodně lidí mmap doporučuje ideálně pro velké soubory. např.
tady https://blog.askesis.pl/post/2019/02/mmap.html [5] https://stackoverflow.com/questions/258091/when-should-i-use-mmap-for-file-a...
[6]
Zdenek pripravto
čt 13. 8. 2020 v 14:22 odesílatel Ondrej Beranek rainbof@gmail.com napsal:
Poutave vysvetleni, dobra prace diky.
čt 13. 8. 2020 v 13:02 odesílatel Pavel Snajdr snajpa@snajpa.net napsal:
Ahojte,
sliboval jsem (vetsinou off-list), ze shnu pak resenici s pameti na vpsAdminOS, tak tady to je :)
Kdyz chce programator dneska z aplikace pracovat s velkym souborem, je docela rozsirenym pristupem, si takovy soubor namapovat do pameti pomoci mmap(2) syscallu.
To zpusobi, ze se soubor ocitne ve virtualnim pametovem prostoru procesu, tj. ten program si pak muze sahat do toho souboru prostym pristupovanim do pameti (nabizi se teda snadny ukladani napr. Cckovych structu do souboru, pristup pres pointerovou aritmetiku, atd.).
Linux cachuje takovy napamovany soubor po strankach, protoze samotnou pamet spravuje po strankach (1 stranka pameti je na x64 velka 4 kB, huge pages jsou potom dalsi extra story na jindy...). Jakmile aplikace chce precist nejaka data, Linux na pozadi, pokud uz to neudelal, pro ta data alokuje stranku fyzicke pameti, aby ta data mela realne, kde sedet, precte je do te stranky z disku (nebo kde ten soubor je) a pak tu
stranku namapuje do prislusneho mista virtualniho pametoveho prostoru naseho procesu, ktery ta data cte.
Jadro vede mapovane stranky v evidenci pomoci LRU listu, coz je datova struktura, seznam, ktery se vyznacuje tim, ze vede v evidenci, ktera polozka byla pouzita naposled (tak, ze se meni pri jejim pouziti jeji poradi na zacatek seznamu).
Kdyz vsechno funguje jak ma, v realne fyzicke pameti jsou pouzivana ctena data a jeste nezapsane "pospinene" (dirty) stranky, do kterych se psalo, tj. je u nich naplanovano, aby se co nejrychleji dostaly na disk (pokud teda cely soubor nebyl otevreny s flagem O_SYNC, nebo podobne, co by vynutilo kazdou zmenu zapsat na disk ihned, nez Linux vrati kontrolu aplikaci pri tom zapisu do mapovaneho souboru; to neni tak caste a to je nam ted "jedno").
Zapis je nastesti vyreseny dobre, Linux ma na to mechanismus, kteremu rika "writeback throttle"; kdyz detekuje, ze se zacina RAM plnit vic, nez je zdravo, zacne aplikaci ty zapisujici pristupy adekvatne zpomalovat. Tohle "impedancni prizpusobeni" funguje vcelku dobre, navic funguje dostatecne dobre i pod memory cgroup.
Memory cgroup je mechanismus, kterym omezujeme pridelenou pamet kontejnerum pod Linuxem - je to volitelna sada dalsich pocitadel vyuziti pameti, nad zakladni systemove, plus vydeleni ukazatelu na LRU, writeback a dalsi cache, aby se dalo pekne vest takovehle seznamy
stranek v oddelene, mimojine aby bylo jasne, co komu patri, kdyz dojde cas tu pamet jednou odklidit. Ale taky, aby se dalo hlidat maximalni vyuziti pameti na ruzne caches - zdaleka nejen - kvuli prave mapovanym souborum.
Potud vsechno dobre.
To nam tak system nabehne, pospousti se na nem stovka VPSek, vsechny aplikace se krasne rozbehnou, nektere si namapujou soubory, nektere do nich vesele zapisuji data...
System muze bezet klidne mesice bez problemu, vsechno stiha, v pohode. Ty seznamy jsou bezne docela kratke, takze sbirka jadernych threadu "kswapd" je na pozadi pekne stiha prochazet a odklizet, jak se postupne nektere memory cgroupy dostavaji s pameti do uzkych.
Koneckoncu, 4 GB RAM (na jeden kontejner) prelozeno na 4 kB stranky znamena teoretickou maximalni delku jednoho seznamu 1M polozek. To se na 2+ gigahertzovych CPU preci stihne projit rychle, ze.
No a pak se stane, ze po treba dvou mesicich behu systemu najednou zoufaly clen pise, ze mu v kontejneru dochazi pamet, pritom at pocita, jak pocita, nemuze se dopocitat, ze by to zabiraly aplikace - je videt, ze je to tim, ze caches nechteji odcouvavat.
Hm, docela spatenka, jak to mame opravit, kdyz to trva tak dlouho, nez se problem projevi? :-D
Tady nekde bych mel podotknout, ze abych byl schopny to takhle pekne vysvetlit, musel jsem doprojit celou cestu do vyresena, takze ted se to jevi zpetne jako trivka, ale nez jsem prisel na to, z ktere strany ten problem pujde aspon nejak resit...
Kdyz se clovek na takovy trpici system prihlasi, vidi tam zpravidla kswapd0 na 100% a kdyz ma ta masina dva fyzicke CPU, tak tam vidi
vetsinou i kswapd1 v tom samem stavu.
V dmesgu jsou videt out of memory hlasky z jednotlivych kontejneru, jak narazeji na neodkliditelne caches a jadro zoufale zabiji stare procesy, aby udelalo misto pro dalsi.
V tech OOM hlaskach je videt pokazde i stack trace, odkud ta OOM udalost z jadra prisla - vetsina z nich byla vyvolana kvuli cteni do mmaped souboru, coz se pozna tak, ze v tom stacku jsou videt funkce pridavajici LRU stranky na seznam te memory cgroupe.
Tak si rikam, hm, to ma preci snadne reseni, nebudeme uctovat mapovanou pamet do memory cgroup clenu, ale nechame ji v root memory cgroup...
Okay, to by mohlo fungovat, ze?
..a zase, kswapd0/1 na 100%...
To uz jsem se zacal seriozneji zajimat, co se to vlastne deje, co delaji tak dlouho a jak to cele funguje, kdyz to neslo smaznout "izy hackem".
Napad to byl dobry, fungoval by, nebyt mensi drobnosti:
kswapd, kdyz odklizeji caches na pozadi, prohledavaji memory cgroupy stylem "dej mi takovou, ktera zere nejvic a tu odklidime, kdyz to nebude stacit, pujdem na dalsi".
Tj. pokud se objevi jedna cgroup, ktera je vetsi a ma toho vzdycky vic k odklizeni, muze se vzdycky kswapd zahojit na ni a k dalsim se ani
nedostat.
Jedine, kdy se odklizi pamet uplne primo z te memory cgroupy, je tzv. "direct reclaim", cesta kodu primo v momente, kdy je potreba alokovat - ale v tu chvili neni tolik casu na uklizeni, tak se jadro zas tak
nesnazi a nekdy to muze vzdat predcasne a rict, ze pamet nenaslo a vyvola OOM situaci v postizene memory cgroupe.
Hmm... okay, takhle by to neslo, tak zkusme mmaped pamet neuctovat cgroupam vubec a nechme ji v zakladnich systemovych seznamech...
A po trochu zapaseni, bo se v jadre s memory cgroup nepocita, ze by nahodou mmaped pamet nebyla uctovana zadne memory cgroupe, je vyreseno, odchod na parek!
...do chvile, nez tim posleme celou masinu out-of-memory a OOM chyby zacnou prichazet odkudkoliv, ne jen z mmaped readu odzpod z mem-cgroup...
Totiz kdyz byly mmaped soubory uctovany na jeden seznam, ktery neni v memory cgroupe, myslelo si jadro, ze ma hodne volnou ruku v tom, co si muze dovolit nechat nacachovane - ale v tom je potom mensi caveat se ZFS... postupny nahodny random access pattern k datum mmaped souboru nadela z ARC slab caches fragmentovane reseto, jeste kdyz se drzi ty kousky z tech puvodne nactenych dat pri zivote "pripinovanim" na jeden velky seznam, ktery nema duvod couvat, protoze host ma preci vsechnu pamet k dispozici bez limitu :D
No pak a chudaci kswapd, kdyz si s tim bordelem maji nejak poradit a odklidit to, *obzvlast* kdyz jsou jen dva a kdyz pod nima mame (konecne spravne nastavene se spravnym ashiftem) NVMe pole... na te staging node (nyni node1.stg) se tak darilo zaplnit RAM az skoro do mrtva.
Takze co s tim? :)
Snadna reseni dosla, bude potreba odklizet ty seznamy per-limitovana-memory-cgroup.
Na nekolik iteraci jsem nakonec dospel k patchi, ktery spusti per-NUMA-node "ksoftlimd" thready, pro kazdou memory cgroupu, ktera ma nastaveny soft_limit.
Ksoftlimd pak dela presne toto - prochazi seznamy svoji memory cgroupy a drzi si je okolo soft_limitu.
Kswapd maji o praci s memory cgroupama min, pokud je jadro nastavene v rezimu, ze ma ksoftlimd poustet automaticky (da se tez spoustet jen rucne).
My jsme zatim defaultne zvolili soft_limit jako watermark, nad ktery se ma ksoftlimd snazit vic odklizet, nastavujeme ho na 80% pameti kontejneru - ale do budoucna mozna tohle jeste predelam na nejakou vetsi automatiku, podle toho, jak kde se ukazou pripadne nedostatky.
Tedy, vysledna situace je, ze pokud aplikace zerou min, jak 80% pameti, ale je co drzet v RAM jako cache, bude mit kontejner vyuzito okolo tech 80% - bude to videt normalne jako aplikacni pamet a zbytek jako caches. Uz by se nemelo stat, ze vyuziti stoupne az ke 100% kvuli caches a ze dojde k OOM a zabijeni procesu.
Zaverem bych jeste zminil ty patche:
Pokus mmaped soubory nauctovat root mem cgroupe:
https://github.com/vpsfreecz/linux/commit/d42232f89795 [1]
Pokus mmaped soubory mem cgroupam neuctovat vubec (popis commitu je blbe a celkove je nedocisteny, nebyl jsem s tim spokojeny a nechtel jsem tim travit vic casu, radsi jsem koumal, co dal, at the time...) ->
https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95 [2]
A finalne, aktualne nasazena verze ksoftlimd patche:
https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d [3]
A uplne-uplne zaverem: linux kernel neni advanced black magic. Je to jen strasne velka a nekdy dost neforemna kupa C kodu, ktery potrebuje
schopne a ochotne instalatery.
V koncinach memory cgroup + memory managementu je teda hodne, co zlepsovat, a vubec to neni raketova veda... Teda obecne, na kontejnerizace v Linuxu je dost co resit.
Takze kdybyste s tim jadernym vyvojem nekdo chtel pomoct, stavte se na IRC, nebo v Base48 v Brne pokecat, neco vymyslime, bude to zabava, trust me ;)
/snajpa _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [4]
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [4]
Links:
[1] https://github.com/vpsfreecz/linux/commit/d42232f89795 [2] https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95 [3] https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d [4] http://lists.vpsfree.cz/listinfo/community-list [5] https://blog.askesis.pl/post/2019/02/mmap.html [6] https://stackoverflow.com/questions/258091/when-should-i-use-mmap-for-file-a...
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Já jsem právě měl za to, že je spíše kvůli tomu, že se cgroups začalo právě více používat a že tam některé takové situace právě nebyly dořešené. Tzn, že se to sice týká LXC, ale spíše jádra a cgroups jako takových a že se to spíše ukázalo přímo na LXC, jelikož se začíná pro tyto situace používat více. V minulosti to bylo KVM a teď se lidem líbí více tohle. Možná to ale pouze špatně chápu :) Zdenek.
pá 14. 8. 2020 v 14:06 odesílatel Petr Žitný petr@zitny.net napsal:
Cus,
me to u jednoho klienta taky trapi, narazime presne na to co cca popisujes. Zejmena u DEV stroju, kde se to dost toci a zaroven je tam dost velky overcommit na vsech prostredkach. A ano, taky se to deje nekdy od tak 60 do 120dne uptime, pak uz to vetsinou nevydrzime a otocime :-)
Nicmene tenhle problem v LXC je tak 2+roky a trapi nas to teda na LXC & BTRFS & cgroups.
--
Petr Zitny
Dne 14.08.2020 v 9:12 Pavel Snajdr napsal(a):
Pokud vim, tak u Proxmoxu celou tu kontejnerovou cast dost utlumili prave s tim, jak umrelo OpenVZ jadro - ted to proste nemaji, jak navarit lip, nez vsichni ostatni se standardnim Linuxem.
Tj. bude je to trapit :)
Otazka je, kdo vlastne kde ma potrebu na tech serverech i realne neco poustet.
Ve spouste firemnich prostredi se nakoupi hromada HW a pak se z toho nevyuziva realne ani 1%... takze, ono to "v malem" bude vzdycky jak uchodit. Proste prinejhorsim shodis pametove limity uplne, zejo...
Kdyz to ma stejne jenom jednoho admina, nebo jeden adminsky tym, co se o to stara...
/snajpa
On 2020-08-14 07:37, zd nex wrote:
Dobrá práce, máš můj obdiv.
Zeptám se myslíš, že v Proxmoxu narazili na podobný problém?
Přeci jen je to LXC & ZFS a cgroups? Určitě jsou tam aplikace, které také používají mmap, ne? Několikrát jsem četl, že hodně lidí mmap doporučuje ideálně pro velké soubory. např.
https://stackoverflow.com/questions/258091/when-should-i-use-mmap-for-file-a...
[6]
Zdenek pripravto
čt 13. 8. 2020 v 14:22 odesílatel Ondrej Beranek rainbof@gmail.com napsal:
Poutave vysvetleni, dobra prace diky.
čt 13. 8. 2020 v 13:02 odesílatel Pavel Snajdr snajpa@snajpa.net napsal:
Ahojte,
sliboval jsem (vetsinou off-list), ze shnu pak resenici s pameti na vpsAdminOS, tak tady to je :)
Kdyz chce programator dneska z aplikace pracovat s velkym souborem, je docela rozsirenym pristupem, si takovy soubor namapovat do pameti pomoci mmap(2) syscallu.
To zpusobi, ze se soubor ocitne ve virtualnim pametovem prostoru procesu, tj. ten program si pak muze sahat do toho souboru prostym pristupovanim do pameti (nabizi se teda snadny ukladani napr. Cckovych structu do souboru, pristup pres pointerovou aritmetiku, atd.).
Linux cachuje takovy napamovany soubor po strankach, protoze samotnou pamet spravuje po strankach (1 stranka pameti je na x64 velka 4 kB, huge pages jsou potom dalsi extra story na jindy...). Jakmile aplikace chce precist nejaka data, Linux na pozadi, pokud uz to neudelal, pro ta data alokuje stranku fyzicke pameti, aby ta data mela realne, kde sedet, precte je do te stranky z disku (nebo kde ten soubor je) a pak tu
stranku namapuje do prislusneho mista virtualniho pametoveho prostoru naseho procesu, ktery ta data cte.
Jadro vede mapovane stranky v evidenci pomoci LRU listu, coz je datova struktura, seznam, ktery se vyznacuje tim, ze vede v evidenci, ktera polozka byla pouzita naposled (tak, ze se meni pri jejim pouziti jeji poradi na zacatek seznamu).
Kdyz vsechno funguje jak ma, v realne fyzicke pameti jsou pouzivana ctena data a jeste nezapsane "pospinene" (dirty) stranky, do kterych se psalo, tj. je u nich naplanovano, aby se co nejrychleji dostaly na disk (pokud teda cely soubor nebyl otevreny s flagem O_SYNC, nebo podobne, co by vynutilo kazdou zmenu zapsat na disk ihned, nez Linux vrati kontrolu aplikaci pri tom zapisu do mapovaneho souboru; to neni tak caste a to je nam ted "jedno").
Zapis je nastesti vyreseny dobre, Linux ma na to mechanismus, kteremu rika "writeback throttle"; kdyz detekuje, ze se zacina RAM plnit vic, nez je zdravo, zacne aplikaci ty zapisujici pristupy adekvatne zpomalovat. Tohle "impedancni prizpusobeni" funguje vcelku dobre, navic funguje dostatecne dobre i pod memory cgroup.
Memory cgroup je mechanismus, kterym omezujeme pridelenou pamet kontejnerum pod Linuxem - je to volitelna sada dalsich pocitadel vyuziti pameti, nad zakladni systemove, plus vydeleni ukazatelu na LRU, writeback a dalsi cache, aby se dalo pekne vest takovehle seznamy
stranek v oddelene, mimojine aby bylo jasne, co komu patri, kdyz dojde cas tu pamet jednou odklidit. Ale taky, aby se dalo hlidat maximalni vyuziti pameti na ruzne caches - zdaleka nejen - kvuli prave mapovanym souborum.
Potud vsechno dobre.
To nam tak system nabehne, pospousti se na nem stovka VPSek, vsechny aplikace se krasne rozbehnou, nektere si namapujou soubory, nektere do nich vesele zapisuji data...
System muze bezet klidne mesice bez problemu, vsechno stiha, v pohode. Ty seznamy jsou bezne docela kratke, takze sbirka jadernych threadu "kswapd" je na pozadi pekne stiha prochazet a odklizet, jak se postupne nektere memory cgroupy dostavaji s pameti do uzkych.
Koneckoncu, 4 GB RAM (na jeden kontejner) prelozeno na 4 kB stranky znamena teoretickou maximalni delku jednoho seznamu 1M polozek. To se na 2+ gigahertzovych CPU preci stihne projit rychle, ze.
No a pak se stane, ze po treba dvou mesicich behu systemu najednou zoufaly clen pise, ze mu v kontejneru dochazi pamet, pritom at pocita, jak pocita, nemuze se dopocitat, ze by to zabiraly aplikace - je videt, ze je to tim, ze caches nechteji odcouvavat.
Hm, docela spatenka, jak to mame opravit, kdyz to trva tak dlouho, nez se problem projevi? :-D
Tady nekde bych mel podotknout, ze abych byl schopny to takhle pekne vysvetlit, musel jsem doprojit celou cestu do vyresena, takze ted se to jevi zpetne jako trivka, ale nez jsem prisel na to, z ktere strany ten problem pujde aspon nejak resit...
Kdyz se clovek na takovy trpici system prihlasi, vidi tam zpravidla kswapd0 na 100% a kdyz ma ta masina dva fyzicke CPU, tak tam vidi
vetsinou i kswapd1 v tom samem stavu.
V dmesgu jsou videt out of memory hlasky z jednotlivych kontejneru, jak narazeji na neodkliditelne caches a jadro zoufale zabiji stare procesy, aby udelalo misto pro dalsi.
V tech OOM hlaskach je videt pokazde i stack trace, odkud ta OOM udalost z jadra prisla - vetsina z nich byla vyvolana kvuli cteni do mmaped souboru, coz se pozna tak, ze v tom stacku jsou videt funkce pridavajici LRU stranky na seznam te memory cgroupe.
Tak si rikam, hm, to ma preci snadne reseni, nebudeme uctovat mapovanou pamet do memory cgroup clenu, ale nechame ji v root memory cgroup...
Okay, to by mohlo fungovat, ze?
..a zase, kswapd0/1 na 100%...
To uz jsem se zacal seriozneji zajimat, co se to vlastne deje, co delaji tak dlouho a jak to cele funguje, kdyz to neslo smaznout "izy hackem".
Napad to byl dobry, fungoval by, nebyt mensi drobnosti:
kswapd, kdyz odklizeji caches na pozadi, prohledavaji memory cgroupy stylem "dej mi takovou, ktera zere nejvic a tu odklidime, kdyz to nebude stacit, pujdem na dalsi".
Tj. pokud se objevi jedna cgroup, ktera je vetsi a ma toho vzdycky vic k odklizeni, muze se vzdycky kswapd zahojit na ni a k dalsim se ani
nedostat.
Jedine, kdy se odklizi pamet uplne primo z te memory cgroupy, je tzv. "direct reclaim", cesta kodu primo v momente, kdy je potreba alokovat - ale v tu chvili neni tolik casu na uklizeni, tak se jadro zas tak
nesnazi a nekdy to muze vzdat predcasne a rict, ze pamet nenaslo a vyvola OOM situaci v postizene memory cgroupe.
Hmm... okay, takhle by to neslo, tak zkusme mmaped pamet neuctovat cgroupam vubec a nechme ji v zakladnich systemovych seznamech...
A po trochu zapaseni, bo se v jadre s memory cgroup nepocita, ze by nahodou mmaped pamet nebyla uctovana zadne memory cgroupe, je vyreseno, odchod na parek!
...do chvile, nez tim posleme celou masinu out-of-memory a OOM chyby zacnou prichazet odkudkoliv, ne jen z mmaped readu odzpod z mem-cgroup...
Totiz kdyz byly mmaped soubory uctovany na jeden seznam, ktery neni v memory cgroupe, myslelo si jadro, ze ma hodne volnou ruku v tom, co si muze dovolit nechat nacachovane - ale v tom je potom mensi caveat se ZFS... postupny nahodny random access pattern k datum mmaped souboru nadela z ARC slab caches fragmentovane reseto, jeste kdyz se drzi ty kousky z tech puvodne nactenych dat pri zivote "pripinovanim" na jeden velky seznam, ktery nema duvod couvat, protoze host ma preci vsechnu pamet k dispozici bez limitu :D
No pak a chudaci kswapd, kdyz si s tim bordelem maji nejak poradit a odklidit to, *obzvlast* kdyz jsou jen dva a kdyz pod nima mame (konecne spravne nastavene se spravnym ashiftem) NVMe pole... na te staging node (nyni node1.stg) se tak darilo zaplnit RAM az skoro do mrtva.
Takze co s tim? :)
Snadna reseni dosla, bude potreba odklizet ty seznamy per-limitovana-memory-cgroup.
Na nekolik iteraci jsem nakonec dospel k patchi, ktery spusti per-NUMA-node "ksoftlimd" thready, pro kazdou memory cgroupu, ktera ma nastaveny soft_limit.
Ksoftlimd pak dela presne toto - prochazi seznamy svoji memory cgroupy a drzi si je okolo soft_limitu.
Kswapd maji o praci s memory cgroupama min, pokud je jadro nastavene v rezimu, ze ma ksoftlimd poustet automaticky (da se tez spoustet jen rucne).
My jsme zatim defaultne zvolili soft_limit jako watermark, nad ktery se ma ksoftlimd snazit vic odklizet, nastavujeme ho na 80% pameti kontejneru - ale do budoucna mozna tohle jeste predelam na nejakou vetsi automatiku, podle toho, jak kde se ukazou pripadne nedostatky.
Tedy, vysledna situace je, ze pokud aplikace zerou min, jak 80% pameti, ale je co drzet v RAM jako cache, bude mit kontejner vyuzito okolo tech 80% - bude to videt normalne jako aplikacni pamet a zbytek jako caches. Uz by se nemelo stat, ze vyuziti stoupne az ke 100% kvuli caches a ze dojde k OOM a zabijeni procesu.
Zaverem bych jeste zminil ty patche:
Pokus mmaped soubory nauctovat root mem cgroupe:
https://github.com/vpsfreecz/linux/commit/d42232f89795 [1]
Pokus mmaped soubory mem cgroupam neuctovat vubec (popis commitu je blbe a celkove je nedocisteny, nebyl jsem s tim spokojeny a nechtel jsem tim travit vic casu, radsi jsem koumal, co dal, at the time...) ->
https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95 [2]
A finalne, aktualne nasazena verze ksoftlimd patche:
https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d [3]
A uplne-uplne zaverem: linux kernel neni advanced black magic. Je to jen strasne velka a nekdy dost neforemna kupa C kodu, ktery potrebuje
schopne a ochotne instalatery.
V koncinach memory cgroup + memory managementu je teda hodne, co zlepsovat, a vubec to neni raketova veda... Teda obecne, na kontejnerizace v Linuxu je dost co resit.
Takze kdybyste s tim jadernym vyvojem nekdo chtel pomoct, stavte se na IRC, nebo v Base48 v Brne pokecat, neco vymyslime, bude to zabava, trust me ;)
/snajpa _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [4]
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [4]
Links:
[1] https://github.com/vpsfreecz/linux/commit/d42232f89795 [2] https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95 [3] https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d [4] http://lists.vpsfree.cz/listinfo/community-list [5] https://blog.askesis.pl/post/2019/02/mmap.html [6]
https://stackoverflow.com/questions/258091/when-should-i-use-mmap-for-file-a...
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Jen tak mimo, jak by se to chovalo s EXT4? Tím netvrdím, že to chci, spíše je otázka jaký je tam ten vztah cgroups & mmap & filesystem?
pá 14. 8. 2020 v 14:29 odesílatel zd nex zdnexnet@gmail.com napsal:
Já jsem právě měl za to, že je spíše kvůli tomu, že se cgroups začalo právě více používat a že tam některé takové situace právě nebyly dořešené. Tzn, že se to sice týká LXC, ale spíše jádra a cgroups jako takových a že se to spíše ukázalo přímo na LXC, jelikož se začíná pro tyto situace používat více. V minulosti to bylo KVM a teď se lidem líbí více tohle. Možná to ale pouze špatně chápu :) Zdenek.
pá 14. 8. 2020 v 14:06 odesílatel Petr Žitný petr@zitny.net napsal:
Cus,
me to u jednoho klienta taky trapi, narazime presne na to co cca popisujes. Zejmena u DEV stroju, kde se to dost toci a zaroven je tam dost velky overcommit na vsech prostredkach. A ano, taky se to deje nekdy od tak 60 do 120dne uptime, pak uz to vetsinou nevydrzime a otocime :-)
Nicmene tenhle problem v LXC je tak 2+roky a trapi nas to teda na LXC & BTRFS & cgroups.
--
Petr Zitny
Dne 14.08.2020 v 9:12 Pavel Snajdr napsal(a):
Pokud vim, tak u Proxmoxu celou tu kontejnerovou cast dost utlumili prave s tim, jak umrelo OpenVZ jadro - ted to proste nemaji, jak navarit lip, nez vsichni ostatni se standardnim Linuxem.
Tj. bude je to trapit :)
Otazka je, kdo vlastne kde ma potrebu na tech serverech i realne neco poustet.
Ve spouste firemnich prostredi se nakoupi hromada HW a pak se z toho nevyuziva realne ani 1%... takze, ono to "v malem" bude vzdycky jak uchodit. Proste prinejhorsim shodis pametove limity uplne, zejo...
Kdyz to ma stejne jenom jednoho admina, nebo jeden adminsky tym, co se o to stara...
/snajpa
On 2020-08-14 07:37, zd nex wrote:
Dobrá práce, máš můj obdiv.
Zeptám se myslíš, že v Proxmoxu narazili na podobný problém?
Přeci jen je to LXC & ZFS a cgroups? Určitě jsou tam aplikace, které také používají mmap, ne? Několikrát jsem četl, že hodně lidí mmap doporučuje ideálně pro velké soubory. např.
https://stackoverflow.com/questions/258091/when-should-i-use-mmap-for-file-a...
[6]
Zdenek pripravto
čt 13. 8. 2020 v 14:22 odesílatel Ondrej Beranek rainbof@gmail.com napsal:
Poutave vysvetleni, dobra prace diky.
čt 13. 8. 2020 v 13:02 odesílatel Pavel Snajdr snajpa@snajpa.net napsal:
Ahojte,
sliboval jsem (vetsinou off-list), ze shnu pak resenici s pameti na vpsAdminOS, tak tady to je :)
Kdyz chce programator dneska z aplikace pracovat s velkym souborem, je docela rozsirenym pristupem, si takovy soubor namapovat do pameti pomoci mmap(2) syscallu.
To zpusobi, ze se soubor ocitne ve virtualnim pametovem prostoru procesu, tj. ten program si pak muze sahat do toho souboru prostym pristupovanim do pameti (nabizi se teda snadny ukladani napr. Cckovych structu do souboru, pristup pres pointerovou aritmetiku, atd.).
Linux cachuje takovy napamovany soubor po strankach, protoze samotnou pamet spravuje po strankach (1 stranka pameti je na x64 velka 4 kB, huge pages jsou potom dalsi extra story na jindy...). Jakmile aplikace chce precist nejaka data, Linux na pozadi, pokud uz to neudelal, pro ta data alokuje stranku fyzicke pameti, aby ta data mela realne, kde sedet, precte je do te stranky z disku (nebo kde ten soubor je) a pak tu
stranku namapuje do prislusneho mista virtualniho pametoveho prostoru naseho procesu, ktery ta data cte.
Jadro vede mapovane stranky v evidenci pomoci LRU listu, coz je datova struktura, seznam, ktery se vyznacuje tim, ze vede v evidenci, ktera polozka byla pouzita naposled (tak, ze se meni pri jejim pouziti jeji poradi na zacatek seznamu).
Kdyz vsechno funguje jak ma, v realne fyzicke pameti jsou pouzivana ctena data a jeste nezapsane "pospinene" (dirty) stranky, do kterych se psalo, tj. je u nich naplanovano, aby se co nejrychleji dostaly na disk (pokud teda cely soubor nebyl otevreny s flagem O_SYNC, nebo podobne, co by vynutilo kazdou zmenu zapsat na disk ihned, nez Linux vrati kontrolu aplikaci pri tom zapisu do mapovaneho souboru; to neni tak caste a to je nam ted "jedno").
Zapis je nastesti vyreseny dobre, Linux ma na to mechanismus, kteremu rika "writeback throttle"; kdyz detekuje, ze se zacina RAM plnit vic, nez je zdravo, zacne aplikaci ty zapisujici pristupy adekvatne zpomalovat. Tohle "impedancni prizpusobeni" funguje vcelku dobre, navic funguje dostatecne dobre i pod memory cgroup.
Memory cgroup je mechanismus, kterym omezujeme pridelenou pamet kontejnerum pod Linuxem - je to volitelna sada dalsich pocitadel vyuziti pameti, nad zakladni systemove, plus vydeleni ukazatelu na LRU, writeback a dalsi cache, aby se dalo pekne vest takovehle seznamy
stranek v oddelene, mimojine aby bylo jasne, co komu patri, kdyz dojde cas tu pamet jednou odklidit. Ale taky, aby se dalo hlidat maximalni vyuziti pameti na ruzne caches - zdaleka nejen - kvuli prave mapovanym souborum.
Potud vsechno dobre.
To nam tak system nabehne, pospousti se na nem stovka VPSek, vsechny aplikace se krasne rozbehnou, nektere si namapujou soubory, nektere do nich vesele zapisuji data...
System muze bezet klidne mesice bez problemu, vsechno stiha, v pohode. Ty seznamy jsou bezne docela kratke, takze sbirka jadernych threadu "kswapd" je na pozadi pekne stiha prochazet a odklizet, jak se postupne nektere memory cgroupy dostavaji s pameti do uzkych.
Koneckoncu, 4 GB RAM (na jeden kontejner) prelozeno na 4 kB stranky znamena teoretickou maximalni delku jednoho seznamu 1M polozek. To se na 2+ gigahertzovych CPU preci stihne projit rychle, ze.
No a pak se stane, ze po treba dvou mesicich behu systemu najednou zoufaly clen pise, ze mu v kontejneru dochazi pamet, pritom at pocita, jak pocita, nemuze se dopocitat, ze by to zabiraly aplikace - je videt, ze je to tim, ze caches nechteji odcouvavat.
Hm, docela spatenka, jak to mame opravit, kdyz to trva tak dlouho, nez se problem projevi? :-D
Tady nekde bych mel podotknout, ze abych byl schopny to takhle pekne vysvetlit, musel jsem doprojit celou cestu do vyresena, takze ted se to jevi zpetne jako trivka, ale nez jsem prisel na to, z ktere strany ten problem pujde aspon nejak resit...
Kdyz se clovek na takovy trpici system prihlasi, vidi tam zpravidla kswapd0 na 100% a kdyz ma ta masina dva fyzicke CPU, tak tam vidi
vetsinou i kswapd1 v tom samem stavu.
V dmesgu jsou videt out of memory hlasky z jednotlivych kontejneru, jak narazeji na neodkliditelne caches a jadro zoufale zabiji stare procesy, aby udelalo misto pro dalsi.
V tech OOM hlaskach je videt pokazde i stack trace, odkud ta OOM udalost z jadra prisla - vetsina z nich byla vyvolana kvuli cteni do mmaped souboru, coz se pozna tak, ze v tom stacku jsou videt funkce pridavajici LRU stranky na seznam te memory cgroupe.
Tak si rikam, hm, to ma preci snadne reseni, nebudeme uctovat mapovanou pamet do memory cgroup clenu, ale nechame ji v root memory cgroup...
Okay, to by mohlo fungovat, ze?
..a zase, kswapd0/1 na 100%...
To uz jsem se zacal seriozneji zajimat, co se to vlastne deje, co delaji tak dlouho a jak to cele funguje, kdyz to neslo smaznout "izy hackem".
Napad to byl dobry, fungoval by, nebyt mensi drobnosti:
kswapd, kdyz odklizeji caches na pozadi, prohledavaji memory cgroupy stylem "dej mi takovou, ktera zere nejvic a tu odklidime, kdyz to nebude stacit, pujdem na dalsi".
Tj. pokud se objevi jedna cgroup, ktera je vetsi a ma toho vzdycky vic k odklizeni, muze se vzdycky kswapd zahojit na ni a k dalsim se ani
nedostat.
Jedine, kdy se odklizi pamet uplne primo z te memory cgroupy, je tzv. "direct reclaim", cesta kodu primo v momente, kdy je potreba alokovat - ale v tu chvili neni tolik casu na uklizeni, tak se jadro zas tak
nesnazi a nekdy to muze vzdat predcasne a rict, ze pamet nenaslo a vyvola OOM situaci v postizene memory cgroupe.
Hmm... okay, takhle by to neslo, tak zkusme mmaped pamet neuctovat cgroupam vubec a nechme ji v zakladnich systemovych seznamech...
A po trochu zapaseni, bo se v jadre s memory cgroup nepocita, ze by nahodou mmaped pamet nebyla uctovana zadne memory cgroupe, je vyreseno, odchod na parek!
...do chvile, nez tim posleme celou masinu out-of-memory a OOM chyby zacnou prichazet odkudkoliv, ne jen z mmaped readu odzpod z mem-cgroup...
Totiz kdyz byly mmaped soubory uctovany na jeden seznam, ktery neni v memory cgroupe, myslelo si jadro, ze ma hodne volnou ruku v tom, co si muze dovolit nechat nacachovane - ale v tom je potom mensi caveat se ZFS... postupny nahodny random access pattern k datum mmaped souboru nadela z ARC slab caches fragmentovane reseto, jeste kdyz se drzi ty kousky z tech puvodne nactenych dat pri zivote "pripinovanim" na jeden velky seznam, ktery nema duvod couvat, protoze host ma preci vsechnu pamet k dispozici bez limitu :D
No pak a chudaci kswapd, kdyz si s tim bordelem maji nejak poradit a odklidit to, *obzvlast* kdyz jsou jen dva a kdyz pod nima mame (konecne spravne nastavene se spravnym ashiftem) NVMe pole... na te staging node (nyni node1.stg) se tak darilo zaplnit RAM az skoro do mrtva.
Takze co s tim? :)
Snadna reseni dosla, bude potreba odklizet ty seznamy per-limitovana-memory-cgroup.
Na nekolik iteraci jsem nakonec dospel k patchi, ktery spusti per-NUMA-node "ksoftlimd" thready, pro kazdou memory cgroupu, ktera ma nastaveny soft_limit.
Ksoftlimd pak dela presne toto - prochazi seznamy svoji memory cgroupy a drzi si je okolo soft_limitu.
Kswapd maji o praci s memory cgroupama min, pokud je jadro nastavene v rezimu, ze ma ksoftlimd poustet automaticky (da se tez spoustet jen rucne).
My jsme zatim defaultne zvolili soft_limit jako watermark, nad ktery se ma ksoftlimd snazit vic odklizet, nastavujeme ho na 80% pameti kontejneru - ale do budoucna mozna tohle jeste predelam na nejakou vetsi automatiku, podle toho, jak kde se ukazou pripadne nedostatky.
Tedy, vysledna situace je, ze pokud aplikace zerou min, jak 80% pameti, ale je co drzet v RAM jako cache, bude mit kontejner vyuzito okolo tech 80% - bude to videt normalne jako aplikacni pamet a zbytek jako caches. Uz by se nemelo stat, ze vyuziti stoupne az ke 100% kvuli caches a ze dojde k OOM a zabijeni procesu.
Zaverem bych jeste zminil ty patche:
Pokus mmaped soubory nauctovat root mem cgroupe:
https://github.com/vpsfreecz/linux/commit/d42232f89795 [1]
Pokus mmaped soubory mem cgroupam neuctovat vubec (popis commitu je blbe a celkove je nedocisteny, nebyl jsem s tim spokojeny a nechtel jsem tim travit vic casu, radsi jsem koumal, co dal, at the time...) ->
https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95 [2]
A finalne, aktualne nasazena verze ksoftlimd patche:
https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d [3]
A uplne-uplne zaverem: linux kernel neni advanced black magic. Je to jen strasne velka a nekdy dost neforemna kupa C kodu, ktery potrebuje
schopne a ochotne instalatery.
V koncinach memory cgroup + memory managementu je teda hodne, co zlepsovat, a vubec to neni raketova veda... Teda obecne, na kontejnerizace v Linuxu je dost co resit.
Takze kdybyste s tim jadernym vyvojem nekdo chtel pomoct, stavte se na IRC, nebo v Base48 v Brne pokecat, neco vymyslime, bude to zabava, trust me ;)
/snajpa _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [4]
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [4]
Links:
[1] https://github.com/vpsfreecz/linux/commit/d42232f89795 [2] https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95 [3] https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d [4] http://lists.vpsfree.cz/listinfo/community-list [5] https://blog.askesis.pl/post/2019/02/mmap.html [6]
https://stackoverflow.com/questions/258091/when-should-i-use-mmap-for-file-a...
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Jo, chapes to spatne ;)
1. s filesystemem to nesouvisi, souvislost se ZFS byla v jednom konkretnim pripade, co jsem myslim dostatecne vysvetlil v prvnim mailu :)
2. LXC je userspace technologie, v jadre jsou to vzdy jen namespaces a cgroups, tedy pokud se tady o necem bavime, tak se hlavne bavime o jadre. Kterym userspace programem je to spustene, je uplne jedno. Tj. muze se to stavat i s Dockerem (ale tam neni obvykle limitovat pamet).
3. Lidem by se libila kontejnerizace od jakziva, ale to by ji Linux musel umet.
Kdyz s tim prisli lidi z OpenVZ za jadernou komunitou, dostali strasny hejt a od te doby nemaji motivaci, ti puvodni lide, co za OpenVZ stali, s tim vubec neco delat.
Kir Kolyshkin treba presel pod Docker, aby vylozene mel klid. Najednou mu stacilo lepit do kupy par tun spaget v Go, protoze se ukazalo, ze Linuxaci vlastne vubec netusi, co to je kontejner, teda da se jim procpat skoro cokoliv, co aspon trochu izoluje - a oni budou nadsene tvrdit, ze to kontejner je :) A navic to dostal lip zaplacene.
Ze zbytku OpenVZ tymu dela na kontejnerizaci akorat Andrej Vagin, to je borec, ktery dela spravne veci.
Jinak v soucasne dobe se kontejnerizaci v jadre venuje jen par premotivovanych lidi z Canonicalu, kteri ale nepremysli nad vecma koncepcne, oni jsou na tom jeste hur - pro ne primarne existuji quick hacky jako defaultni modus operandi, ne ze by jako my "nestihali". Treba takovy Chris Brauner, jeho prace je vylozene bezkoncepcni hura-styl - ono to asi s vanilla linuxem jinak nejde.
Plna virtualizace je proste reseni na mnohem, mnohem min kodu.
Je to neco, co primo do Linuxu nevyzadovalo tolik zmen. Proste se pusti QEMU jako user-space proces a jadro mu umozni kousek veci navic, aby mohlo QEMU nechat bezet nejaky ten kod ""uplne"" oddelene, virtualizovane.
Proto se ujala driv a rozsirila tak moc... ne ze by slo o nejakou uzasnou security navic nebo tak (nakonec se ukazuje ve svetle Spectre a podobnych zranitelnosti, ze to borci s tim tvrzenim, ze je fullvirt bezpecnejsi, dost nabubrele prehaneli).
/snajpa
Jestli to zni, jakoze jsem z toho zatrpkly, tak to zni docela spravne.
Upstream Linuxu je proste jeden velky bordel.
Dojdete za nima, ze jste neco vyresili a mate hotovo a skoro urcite se to do upstreamu nedostane.
Do dneska obdivuju autora Wireguardu, ze to s nima vydrzel a na tolikrat se mu to chtelo prepisovat.
Jeste, kdyby se aspon dalo rict, ze diky tem reviews ten kod opravdu konci lepsim, nez byl.
Ale kez by, proste jen sotva.
U Linuxu je hlavni byt v te komunite videt, byt dostatecne servilni spravcum, ale rozhodne neni dobry predpoklad jit do toho s tim, ze "borci, mam tady pro vas supr vec...".
Pro nejvetsi uspech je potreba ze sebe delat idiota, idealne to rovnou vyvinout znova od podlahy verejne na mailing listu podle toho, jak si kdektery rejpal vzpomene.
Ze casto skoncite s vysledkem, ktery vlastne nechtel nikdo, protoze vlastne ne-uplne-sedi na zadne z puvodnich zadani?
No, vcelku klasicka situace...
Nektere veci jsou pak uplne politicky nepruchodne.
PROSTE ZADNE ID KONTEJNERU V JADRE NEBUDE, OK?
Ze se pak musi vsichni, co vlastne ten kontejner realne chteji, desetinasobne snazit, aby se jim cela ta zplacanina nerozsypala na vsechny strany, aby to opravdu tesnilo, jak ma...
Vytancovat kontejner pod Linuxem je dneska paradni shamansky tanec, jehoz vysledek rozhodne neni zaruceny, paradne se lisi napric verzemi Linuxu a vlastne to jeste porad kontejner az tak neni.
Trochu jo, ale jeste mu dost chybi.
Napr. izolace celeho /proc a /sys...
Braunerovi a ostanim lepicu LXC z Canonicalu proste staci LXCFS a mavnou nad tim rukou, ze mame hotovo...
A pak se clovek divi, ze bashovy `nproc` ukazuje plny pocet jader, ze. A ze spustit build skoro cehokoliv vymlati RAMku, protoze se prave kompilace pusti tolikrat, kolik ma masina fyzickych jader/threadu...
Asi protoze virtualizovat tyhle veci primo v jadre by byl asi neprezitelny hrich, kdyby jadro nahlasilo, jak moc jsou ty procesy v tom kontejneru omezene, rovnou, ze?
A tady se prave narazi na to, ze jadro vubec nema prehled o tom, co to vlastne kontejner je.
Takze jak by mohlo poskytovat spravny obraz o /proc a /sys a dalsich vecech, kdyz na kazde volani, by to muselo slozite zjistovat komplexnim prochazenim spousty vyrobenych namespacu a cgroup - a z toho nejak dovozovat, co vlastne teda ma ten kontejner videt...
A tak je to se vsim s Linuxem.
Nezbyva mi moc jineho, nez sklopit hlavu a nejak tim proste proplouvat - protoze kapital na to, to udelat pro jednou poradne, rozhodne nemam - a i kdybych mel, nafoukanci na LKML by rozhodne nerozdejchali, ze si nekdo zase dovolil prijit tam uz s necim hotovym.
To se musi odotrocit v primem prenosu a clovek musi dat najevo, ze je dostatecne submisivni a nezbyla mu zadna vlastni vule, jak by to chtel, ze se nakomplet ohyba podle sluzebne starych vyvojaru, kteri ani nemuseli vubec pochopit, k cemu kontejnerova technologie je...
/snajpa
</rant>
Já jsem právě pochopil, že LXCFS vzniklo kvůli tomu, že se jim v minulosti nedařilo přesvědčit vývojáře o tom, že by ten kontejner měl i tohle mít oddělené (/proc a /sys). A to je možná ten důvod pro vznik.
pá 14. 8. 2020 v 15:07 odesílatel Pavel Snajdr snajpa@snajpa.net napsal:
Jestli to zni, jakoze jsem z toho zatrpkly, tak to zni docela spravne.
Upstream Linuxu je proste jeden velky bordel.
Dojdete za nima, ze jste neco vyresili a mate hotovo a skoro urcite se to do upstreamu nedostane.
Do dneska obdivuju autora Wireguardu, ze to s nima vydrzel a na tolikrat se mu to chtelo prepisovat.
Jeste, kdyby se aspon dalo rict, ze diky tem reviews ten kod opravdu konci lepsim, nez byl.
Ale kez by, proste jen sotva.
U Linuxu je hlavni byt v te komunite videt, byt dostatecne servilni spravcum, ale rozhodne neni dobry predpoklad jit do toho s tim, ze "borci, mam tady pro vas supr vec...".
Pro nejvetsi uspech je potreba ze sebe delat idiota, idealne to rovnou vyvinout znova od podlahy verejne na mailing listu podle toho, jak si kdektery rejpal vzpomene.
Ze casto skoncite s vysledkem, ktery vlastne nechtel nikdo, protoze vlastne ne-uplne-sedi na zadne z puvodnich zadani?
No, vcelku klasicka situace...
Nektere veci jsou pak uplne politicky nepruchodne.
PROSTE ZADNE ID KONTEJNERU V JADRE NEBUDE, OK?
Ze se pak musi vsichni, co vlastne ten kontejner realne chteji, desetinasobne snazit, aby se jim cela ta zplacanina nerozsypala na vsechny strany, aby to opravdu tesnilo, jak ma...
Vytancovat kontejner pod Linuxem je dneska paradni shamansky tanec, jehoz vysledek rozhodne neni zaruceny, paradne se lisi napric verzemi Linuxu a vlastne to jeste porad kontejner az tak neni.
Trochu jo, ale jeste mu dost chybi.
Napr. izolace celeho /proc a /sys...
Braunerovi a ostanim lepicu LXC z Canonicalu proste staci LXCFS a mavnou nad tim rukou, ze mame hotovo...
A pak se clovek divi, ze bashovy `nproc` ukazuje plny pocet jader, ze. A ze spustit build skoro cehokoliv vymlati RAMku, protoze se prave kompilace pusti tolikrat, kolik ma masina fyzickych jader/threadu...
Asi protoze virtualizovat tyhle veci primo v jadre by byl asi neprezitelny hrich, kdyby jadro nahlasilo, jak moc jsou ty procesy v tom kontejneru omezene, rovnou, ze?
A tady se prave narazi na to, ze jadro vubec nema prehled o tom, co to vlastne kontejner je.
Takze jak by mohlo poskytovat spravny obraz o /proc a /sys a dalsich vecech, kdyz na kazde volani, by to muselo slozite zjistovat komplexnim prochazenim spousty vyrobenych namespacu a cgroup - a z toho nejak dovozovat, co vlastne teda ma ten kontejner videt...
A tak je to se vsim s Linuxem.
Nezbyva mi moc jineho, nez sklopit hlavu a nejak tim proste proplouvat - protoze kapital na to, to udelat pro jednou poradne, rozhodne nemam - a i kdybych mel, nafoukanci na LKML by rozhodne nerozdejchali, ze si nekdo zase dovolil prijit tam uz s necim hotovym.
To se musi odotrocit v primem prenosu a clovek musi dat najevo, ze je dostatecne submisivni a nezbyla mu zadna vlastni vule, jak by to chtel, ze se nakomplet ohyba podle sluzebne starych vyvojaru, kteri ani nemuseli vubec pochopit, k cemu kontejnerova technologie je...
/snajpa
</rant>
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
On 2020-08-14 15:21, zd nex wrote:
Já jsem právě pochopil, že LXCFS vzniklo kvůli tomu, že se jim v minulosti nedařilo přesvědčit vývojáře o tom, že by ten kontejner měl i tohle mít oddělené (/proc a /sys). A to je možná ten důvod pro vznik.
On je to hlavne dost problem, zjistit z jadra, jak by mely ty /proc a /sys pro dany proces, co se na to zrovna pta, vlastne vypadat.
LXCFS o tom ma docela prehled z venku, jako uzivatelsky proces bezici pod realnym rootem. Ale Linux muzete preci mit sestaveny uplne bez /proc...
Takze kdyz budu psat program, pouziju syscall sched_getaffinity(), ktery samozrejme ma nejakou cpu cgroup, ktera by mohla ten proces limitovat, u neceho... Takze se dozvi pekne stav poctu procesoru na cele masine, ne k cemu ma ten kontejner pristup.
Navic cgroupy jsou hierarchicke, takze by se muselo prochazet cgroupy az nahoru ke korenove.
A nekdy nestaci jen zjistit jednu cgroupu, nebo namespace, v kterem ten proces je. Nekdy je potreba to kombinovat (pid a syslog namespace treba, kdyby clovek chtel v "dmesg" videt spravne pidy, jako jsou videt z kontejneru)...
Ty namespaces nemusely vubec byt vyrobene pro jeden proces, ten proces muze bezet jeste v nejakem dalsim sub-kontejneru a cpu cgroup muze sdilet, ale pid namespace muze mit jiny, pritom sdili syslog namespace... a pak do toho syslogu vyber, co mas vlastne napsat, ze. Kdyz nevis, jaky originalni pid namespace patri k tomu vyrobenemu syslog namespace...
Jako vsechno se to da vzdycky nejak nakonec vyresit, ale pridavame, kupime hacky pekne na sebe, misto, aby jich ubyvalo.
Takze ted do Linuxu pristane moznost sledovat procesy pod namespacy, jestli naaahodou nechteji mountovat /proc a /sys, aby to mohlo prevzit z hosta-bezici LXCFS...
Coz zas je hack, ktery to neresi uplne, no.
/snajpa
Zdar,
On 2020-08-14 15:43:36 +0200, Pavel Snajdr wrote:
[..]
A nekdy nestaci jen zjistit jednu cgroupu, nebo namespace, v kterem ten proces je. Nekdy je potreba to kombinovat (pid a syslog namespace treba, kdyby clovek chtel v "dmesg" videt spravne pidy, jako jsou videt z kontejneru)...
Ty namespaces nemusely vubec byt vyrobene pro jeden proces, ten proces muze bezet jeste v nejakem dalsim sub-kontejneru a cpu cgroup muze sdilet, ale pid namespace muze mit jiny, pritom sdili syslog namespace... a pak do toho syslogu vyber, co mas vlastne napsat, ze. Kdyz nevis, jaky originalni pid namespace patri k tomu vyrobenemu syslog namespace...
[..]
Jak to tak cele ctu, myslis si ze je dobre mit separatni namespaces (mysleno v kernelu)? Nebylo by lepsi mit misto nich neco jako "kontainer", ktery by automaticky vynutil stejne namespace pro vsechno?
Jasne, bylo by to mene powerful, na druhou stranu dost mozna snazsi na implementaci (taky dost hadam) a mene derave/snadne pouzit blbe (taky hadam).
Co si tom myslis? Bylo to cele (containers v linuxu) uchopene za spravny konec?
W.
Jak to tak cele ctu, myslis si ze je dobre mit separatni namespaces (mysleno v kernelu)? Nebylo by lepsi mit misto nich neco jako "kontainer", ktery by automaticky vynutil stejne namespace pro vsechno?
Jasne, bylo by to mene powerful, na druhou stranu dost mozna snazsi na implementaci (taky dost hadam) a mene derave/snadne pouzit blbe (taky hadam).
Co si tom myslis? Bylo to cele (containers v linuxu) uchopene za spravny konec?
W.
No to vis... tak to maj vsichni, jen Linux ne.
Solaris/Illumos Zones:
https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/z...
OpenVZ:
https://github.com/OpenVZ/vzkernel/blob/branch-rh7-3.10.0-1127.10.1.vz7.162....
FreeBSD:
https://github.com/freebsd/freebsd/blob/master/sys/sys/jail.h#L155
V Linuxu se rozhodli, ze nic jako 'kontejner' nebudou definovat, ze to nechaji na userspace toolech, at si 'kontejner' rikaji, cemu chteji. Kernel nabizi sbirku volitelnych cgroups + namespaces, ale nic z toho neni povinne.
Zavislosti na sobe trochu maji, coz se pozna podle (IMHO velmi vtipnyho) tanecku, kterym je potreba se protancovat treba prave k plne funkcnimu kontejneru s User namespace... takze to je presne zpusob, jak ty zavislosti delat. Ten a ten namespace musis udelat az po tom a tamtom, jinak nedostanes vysledek, co cekas...
Rekl bych, ze velmi mocnou silou, proc to tak je, je Google. "My mame cgroups a nam to staci, necpete nam, jak mame obalovat svoje aplikace" - ty nejaka kontejnerizace nikdy nezajimala, je zajima, jak bezet to jejich "do not be evil" na velky skale za co nejlevnejc...
Jestli je to uchopene za spravny konec?
Tady je odpoved dvoji: ano a ne, protoze:
1. viz vsechny ostatni rozumnejsi zpusoby kontejnerizace, da se to udelat "spravneji"
2. Microsoft ale do Windows includnul Linux presne kvuli cgroups+namespaces, protoze Docker a dalsi takove technologie... takze z tehle strany se to dostalo mnohem dal, nez kontejnerizace pod FreeBSD... ta ve Windows neni :-D
Je to asi otazka pohledu a ocekavani. Kdo ceka plnotucnou kontejnerizaci ve stylu vsech ostatnich, odchazi zklamany. Kdo potrebuje izolovat jen nektere aspekty sve multi-tenant aplikace, je z toho nadseny :)
/snajpa
- Lidem by se libila kontejnerizace od jakziva, ale to by ji Linux
musel umet.
Jak komu :-) , já to radši zavřu do plnotučného virtuálu a tohle všechno se rázem vyřeší samo z principu. I když taky jsem už podlehl a spouštím si doma přes LXC popelnici na Steam. :-)
Jinak v soucasne dobe se kontejnerizaci v jadre venuje jen par premotivovanych lidi z Canonicalu, kteri ale nepremysli nad vecma koncepcne, oni jsou na tom jeste hur - pro ne primarne existuji quick hacky jako defaultni modus operandi, ne ze by jako my "nestihali". Treba takovy Chris Brauner, jeho prace je vylozene bezkoncepcni hura-styl - ono to asi s vanilla linuxem jinak nejde.
Tady bych si teda trochu rejpnul, protože hned to první řešení "prostě nebudeme účtovat mapovanou paměť do memcg členů" je přesně takový quick hack (a upřímně jsem docela čekal to, co je popsané hned o pár řádků níž - že to udělá bordel někde jinde)
Proto se ujala driv a rozsirila tak moc... ne ze by slo o nejakou uzasnou security navic nebo tak (nakonec se ukazuje ve svetle Spectre a podobnych zranitelnosti, ze to borci s tim tvrzenim, ze je fullvirt bezpecnejsi, dost nabubrele prehaneli).
To je hodně zavádějící argument, kontejnery na Spectre a podobné trpí úplně stejně jako plná virtualizace. Takže pro porovnávání zbývá jen to ostatní a tam je na tom plná virtualizace pořád líp.
Jak komu :-) , já to radši zavřu do plnotučného virtuálu a tohle všechno se rázem vyřeší samo z principu. I když taky jsem už podlehl a spouštím si doma přes LXC popelnici na Steam. :-)
No jestli doma bezis s mitigations=off, tak Ti to muze byt sumak - taky tak bezim virtualizovanou workstation. Jinak bych se teda KVM vyhnul obrovskym obloukem, kdyz po tom reseni chci (jako vzdycky) vyladeny pomer cena/vykon.
Jinak v soucasne dobe se kontejnerizaci v jadre venuje jen par premotivovanych lidi z Canonicalu, kteri ale nepremysli nad vecma koncepcne, oni jsou na tom jeste hur - pro ne primarne existuji quick hacky jako defaultni modus operandi, ne ze by jako my "nestihali". Treba takovy Chris Brauner, jeho prace je vylozene bezkoncepcni hura-styl - ono to asi s vanilla linuxem jinak nejde.
Tady bych si teda trochu rejpnul, protože hned to první řešení "prostě nebudeme účtovat mapovanou paměť do memcg členů" je přesně takový quick hack (a upřímně jsem docela čekal to, co je popsané hned o pár řádků níž - že to udělá bordel někde jinde)
Ja to jako rejpnuti nevidim, protoze to, ze to nejspis nebude fungovat, jsme cekali vsichni (vc. Aithera, ktery byva vuci mym quickhackum docela ve spravnych pripadech skepticky :D).
Proto se ujala driv a rozsirila tak moc... ne ze by slo o nejakou uzasnou security navic nebo tak (nakonec se ukazuje ve svetle Spectre a podobnych zranitelnosti, ze to borci s tim tvrzenim, ze je fullvirt bezpecnejsi, dost nabubrele prehaneli).
To je hodně zavádějící argument, kontejnery na Spectre a podobné trpí úplně stejně jako plná virtualizace. Takže pro porovnávání zbývá jen to ostatní a tam je na tom plná virtualizace pořád líp.
Tak to sotva. Prvni level flushuje caches - a pak se prepnes na program, ktery zase flushuje caches a az ten vybira, ktery ten uzivatelsky program, kvuli kterym je ten stroj vubec pusteny, pobezi.
Fullvirt hypervizor nemuze z techhle mitigaci vyjit dobre, protoze je to dalsi uroven task switchingu, kde se musi davat bacha, aby neco neleakovalo :)
/snajpa
On 14. 08. 20 15:19, Pavel Snajdr wrote:
Jak komu :-) , já to radši zavřu do plnotučného virtuálu a tohle všechno se rázem vyřeší samo z principu. I když taky jsem už podlehl a spouštím si doma přes LXC popelnici na Steam. :-)
No jestli doma bezis s mitigations=off, tak Ti to muze byt sumak - taky tak bezim virtualizovanou workstation. Jinak bych se teda KVM vyhnul obrovskym obloukem, kdyz po tom reseni chci (jako vzdycky) vyladeny pomer cena/vykon.
Já mluvil o datacentru, ale s mitigation=off neběžím ani tam, ani doma. Ale už delší dobu si říkám, že bych přeměřil, kolik výkonu to KVM stojí - při posledním měření to bylo do 10%, což v poměru cena/výkon vychází oproti kontejnerům velice dobře.
(Schválně si někdy s Aitherem sečtěte, kolik vás tenhle jaderný vývoj stojí na "mzdových" nákladech. Téměř určitě byste se dopočítali k tomu, že by prostě bylo levnější nakoupit a provozovat hardware navíc - a čas byste pak mohli věnovat vývoji, ne opravám.)
Tak to sotva. Prvni level flushuje caches - a pak se prepnes na program, ktery zase flushuje caches a az ten vybira, ktery ten uzivatelsky program, kvuli kterym je ten stroj vubec pusteny, pobezi.
Fullvirt hypervizor nemuze z techhle mitigaci vyjit dobre, protoze je to dalsi uroven task switchingu, kde se musi davat bacha, aby neco neleakovalo :)
Pokud si dobře pamatuju, tak výchozí nastavení je, že při přechodu do VM se neflushuje, protože to udělá kernel hosta. Ale uznávám, že v prostředí vpsfree (nebo obecně u VPS) by se na to spolehnout nedalo.
On 2020-08-14 15:49, Jirka Bourek wrote:
On 14. 08. 20 15:19, Pavel Snajdr wrote:
Jak komu :-) , já to radši zavřu do plnotučného virtuálu a tohle všechno se rázem vyřeší samo z principu. I když taky jsem už podlehl a spouštím si doma přes LXC popelnici na Steam. :-)
No jestli doma bezis s mitigations=off, tak Ti to muze byt sumak - taky tak bezim virtualizovanou workstation. Jinak bych se teda KVM vyhnul obrovskym obloukem, kdyz po tom reseni chci (jako vzdycky) vyladeny pomer cena/vykon.
Já mluvil o datacentru, ale s mitigation=off neběžím ani tam, ani doma. Ale už delší dobu si říkám, že bych přeměřil, kolik výkonu to KVM stojí - při posledním měření to bylo do 10%, což v poměru cena/výkon vychází oproti kontejnerům velice dobře.
(Schválně si někdy s Aitherem sečtěte, kolik vás tenhle jaderný vývoj stojí na "mzdových" nákladech. Téměř určitě byste se dopočítali k tomu, že by prostě bylo levnější nakoupit a provozovat hardware navíc
- a čas byste pak mohli věnovat vývoji, ne opravám.)
Absolutni vykon je jedna stranka veci. Kontejnery vyhravaji ale hlavne v tom, ze umoznuji agregovat, jak to fullvirt nikdy neumozni.
Pocitame to pravidelne, neboj ;)
Vyslo by to tak, ze az vymenime kompletne HW za novy, spis bychom z prostredku pripadajicich na jednoho clena museli ubrat, protoze prave se bude mnohem hur agregovat - a nebo se bude agregovat mocne za ztraty vykonu - baloon, ksm... good luck kdyz Ti dojde pamet a chces od hostitele ziskat vic, kdyz on zrovna nema... to Ti pak stoji ten KVM virtual +- cely, protoze proste pamet je k behu dulezita vec a bez toho se nehnem :D
Dokud HW neobmenime, prechod na KVM by znamenal prechod na prostredky o zhruba neco mezi polovicnimi a tretinovymi specifikacemi, nez ted. S novym HW by to vyslo nekam na 80% prostredku, to uz by se asi dalo nejak donavarit.
Ale co kdybychom chteli, spis, kvuli zravosti dnesnich aplikaci, RAMku clenum spis pridat?
S dobre udelanou kontejnerizaci tu moznost mit nejspis budeme.
Podstatne u tech kalklulaci taky je, ze nebyt NixOSu, vyvoj vpsAdminOS by ve dvou lidech ani nebyl mozny.
Takze divat se na to z bezneho manazerskeho pohledu nejde... bezny manazer by mel na miste mrtvicku jen bych rekl Nix. Co to jako je? Ktery velky hrac to pouziva? A je zabito :-D
vpsFree asi nikdy nepujde pocitat a resit skrz tradicni manazerskou optiku, na to je v tom celem prilis nadseni, s tim se ale blbe kalkuluje ;)
A jako kdybychom zasli uplne na hard-hard fakta a cisla... tak jako financni rozdil mezi "hostovat u vpsFree a zivit se tim provozovanim" vs. "hostovat klidne na vlastnim HW a delat cca podobnou napln prace pro nejaky Amazon/Microsoft", vyjde v nasobcich celych cisel v neprospech vpsFree.
Ale je mi o hodne milejsi byt tady v te pozici v komunite "mezi svyma", nez ze sebe delat velke korporatni zvire :-)
Aither je myslim taky rad, ze ma svuj klidek a muze si meditovat prevazne hlavne nad bugy, co si sam vyrobil :-D Nemusi byt v korporatnim SCRUM & agile bullshit kolecku...
Myslim, ze to je pro nas mnohem vetsi hodnota, nez skoncit nestastny, ale s rancem penez na ucte (nebo 3-4 bytama k pronajimani v Praglu nebo tak...).
/snajpa
On 14. 08. 20 16:45, Pavel Snajdr wrote:
On 2020-08-14 15:49, Jirka Bourek wrote:
On 14. 08. 20 15:19, Pavel Snajdr wrote:
Já mluvil o datacentru, ale s mitigation=off neběžím ani tam, ani doma. Ale už delší dobu si říkám, že bych přeměřil, kolik výkonu to KVM stojí - při posledním měření to bylo do 10%, což v poměru cena/výkon vychází oproti kontejnerům velice dobře.
(Schválně si někdy s Aitherem sečtěte, kolik vás tenhle jaderný vývoj stojí na "mzdových" nákladech. Téměř určitě byste se dopočítali k tomu, že by prostě bylo levnější nakoupit a provozovat hardware navíc
- a čas byste pak mohli věnovat vývoji, ne opravám.)
Absolutni vykon je jedna stranka veci. Kontejnery vyhravaji ale hlavne v tom, ze umoznuji agregovat, jak to fullvirt nikdy neumozni.
O tom už jsme se bavili - a jo, pořád bez problémů dokážu na jednu hostitelskou mašinu naskládat tolik serverů, kolik jich tam pustit "nejde" :-)
Pocitame to pravidelne, neboj ;)
Vyslo by to tak, ze az vymenime kompletne HW za novy, spis bychom z prostredku pripadajicich na jednoho clena museli ubrat, protoze prave se bude mnohem hur agregovat - a nebo se bude agregovat mocne za ztraty vykonu - baloon, ksm... good luck kdyz Ti dojde pamet a chces od hostitele ziskat vic, kdyz on zrovna nema... to Ti pak stoji ten KVM virtual +- cely, protoze proste pamet je k behu dulezita vec a bez toho se nehnem :D
Pravda, KSM jsem nepočítal. Na serverech máme jedno jádro vyhrazené pro systém a VS k němu nesmí, aby nehrozilo, že se tam kvůli nějakému bordelu nepůjde ani přihlásit (tak jsem se k tomu dostal a tak jsem to nechal.) ksmd tudíž běží tam, bere si asi 30% výkonu toho jádra a šetří ~55GB. Takže v součtu na Ryzenu je cenou 1% z celkového procesorového výkonu, to jde :-) (U starých strojů s méně jádry jsou to nějaká 3%)
(YMMV, ty servery jsou si dost podobné, co se software týče.)
Situaci, kdy dojde paměť a od hostitele se nedá dostat víc, protože nemá, neberu - ta může nastat u obou technologií stejně. U KVM pak beru jako výhodu to, že v takovém případě má problém host a nepřeleje se to do hostitele. A to ani tím, že bordelář způsobí, že by jádro vytěsnilo data z diskové cache ostatních hostů.
Takze divat se na to z bezneho manazerskeho pohledu nejde... bezny manazer by mel na miste mrtvicku jen bych rekl Nix. Co to jako je? Ktery velky hrac to pouziva? A je zabito :-D
vpsFree asi nikdy nepujde pocitat a resit skrz tradicni manazerskou optiku, na to je v tom celem prilis nadseni, s tim se ale blbe kalkuluje ;)
Což to je jasný, cena na "mzdové" náklady je dobré měřítko, jak moc se něco vyplatí, ale místní specifika se do úvahy musí brát taky. Proto ty kontejnery u vpsfree vychází i finančně - protože děláte jaderné programátory a nejste za to placení tomu odpovídající částkou.
(Možnost, že pracujete na tom, co vás baví, je určitě nefinanční odměna - máte štěstí, že to nejde spočítat a zdanit :-) )
Případného manažera by ovšem měl trefit šlak z to, že celé vpsfree stojí a padá na nadšení dvou lidí :-)
Pravda, KSM jsem nepočítal. Na serverech máme jedno jádro vyhrazené pro systém a VS k němu nesmí, aby nehrozilo, že se tam kvůli nějakému bordelu nepůjde ani přihlásit (tak jsem se k tomu dostal a tak jsem to nechal.) ksmd tudíž běží tam, bere si asi 30% výkonu toho jádra a šetří ~55GB. Takže v součtu na Ryzenu je cenou 1% z celkového procesorového výkonu, to jde :-) (U starých strojů s méně jádry jsou to nějaká 3%)
No ona ta agregace u multi-tenant OS-level prostredi je hlavne o ty RAMce, zejo... kdyz usetris 55GB... to je z kolika?
Kdyz sectes maximalni dovolenou RAM vsem virtualum na tom serveru, na kolik se dostanes?
My jsme _uplne_bezne_ _minimalne_ na dvojnasobku vuci fyzicke RAM stroje, na nekterych masinach jeste o neco vic...
A kdyz node dame tolik RAM, kolik je to sectene maximum, tak je proste vyuzite pod polovinu (pokud to nenechame sezrat ARC, coz vetsinou nema smysl...).
To mame nejakych 500 GB pridelene RAM, kdyz stroj ma 256 GB, a jeste mame podminku, ze na stroji musi viset aspon 40 GB dat v ZFS ARC cache (abychom mohli jit spis na kapacitu a pouzivat rotacni disky). To se preklada ve vic jak 99.9% hitrate z cache, misto cteni z disku.
Takze 540 GB pridelene RAM.
Stroj ma 256 GB, takze "usetrenych" 284 GB.
A to je pri strojich s 256G RAM a adekvatnimi CPU jadry k tomu...
Chteli bychom mirit spis na poradnejsi many-core systemy, abychom mohli agregovat jeste lip - ckeam, ze pri 1 TB RAM a aspon 96 jadrech budem nekde u "usetrenych 2 TB" pri podobne kalkulaci. Zhruba... "porizovacka" takove masiny je zhruba na 4nasobku jednoho stroje, co jsme kupovali do ted, myslim ze by se na to v pohode melo vejit neco okolo obsahu 5-6 tech puvodnich masin.
Ve srovnani se standardnim Linuxovym resenim bychom proste museli tem virtualum ty 4 GB pridelit a doufat, ze si zvladnou vsechno odcachovat samy, protoze RAM na cache uz by fakt nezbyla... a bez ZFS je to stejne skoro-zbytecne nechavat hostu nejak vic RAMky na cachovani dat z disku.
Jo a dalsi drobnost - do tech 4 GB nepocitame na vpsAdminOS "kmem", tj. hlavne TCP buffery, dentries a podobne veci - to se na aktivnim systemu s 4G realne pameti umi taky naskladat klidne na gigabajt i vic, kdyz ta masina obsluhuje hodne vzdalenych spojeni, nebo pracuje s adresari s hodne soubory, atd.
Uctujeme jen mmaped pamet, protoze je v tuhle chvili uz slozitejsi to uctovani do memcg z jadra vykuchat, nez radsi poresit ten ksoftlimd...
/snajpa
On 14. 08. 20 20:02, Pavel Snajdr wrote:
Pravda, KSM jsem nepočítal. Na serverech máme jedno jádro vyhrazené pro systém a VS k němu nesmí, aby nehrozilo, že se tam kvůli nějakému bordelu nepůjde ani přihlásit (tak jsem se k tomu dostal a tak jsem to nechal.) ksmd tudíž běží tam, bere si asi 30% výkonu toho jádra a šetří ~55GB. Takže v součtu na Ryzenu je cenou 1% z celkového procesorového výkonu, to jde :-) (U starých strojů s méně jádry jsou to nějaká 3%)
No ona ta agregace u multi-tenant OS-level prostredi je hlavne o ty RAMce, zejo... kdyz usetris 55GB... to je z kolika?
Tak já nevim, o čem to hlavně je, reagoval jsem na zmínku o ksm a balloon, žejo...
Je to z 266GB alokovaných pro VM při využití 200GB fyzických. Při zachování poměru alokovaných a ušetřených dat by se tím pádem dalo dostat na nějakých 330GB alokovaných pro VM.
Jasně, je to míň než dvojnásobek fyzické, ale taky nejsme na stropu toho řešení - další zvýšení by se nepochybně dalo dosáhnout tím balónem. Ale nemáme tu potřebu. Když si někdo pořídí VM s X GB RAM, tak má X GB RAM a hotovo - pokud je má na cache, tak je má na cache a jejím odebráním bych snižoval výkon toho VM ve prospěch někoho, kdo ji využívá jako aplikační paměť, což mi nepřijde fér.
jejím odebráním bych snižoval výkon toho VM ve prospěch někoho, kdo ji využívá jako aplikační paměť, což mi nepřijde fér.
A kdo z nas tady jede na pocit, ze ;)
Ja mam na mnohokrat overeno, ze to naopak plna virtualizace takhle pekne neumi dat.
Kdyz ty rikas, ze mas asi mozna trochu rezervu, protoze muzes zapnout baloon, tak rikam, ze ho zapnout nemuzes, protoze to zpusobi totalni nedeterminismus v odezvach vsech tech virtualu, ktere nedelaji neco *porad*.
A kdyz rikas, ze mas kousek rezervu, ja rikam, ze my ji mame jeste minimalne dvojnasobnou...
Proste v agregaci nemuzes srovnavat jednoho spravce prostredku, zase, s dvema levely, ktere jen velmi neochotne spolupracuji ;)
/snajpa
On 16. 08. 20 8:09, Pavel Snajdr wrote:
jejím odebráním bych snižoval výkon toho VM ve prospěch někoho, kdo ji využívá jako aplikační paměť, což mi nepřijde fér.
A kdo z nas tady jede na pocit, ze ;)
Ja mam na mnohokrat overeno, ze to naopak plna virtualizace takhle pekne neumi dat.
K tomu jenom připomenu, že už jsme se dříve dopracovali k tomu, že s plnou virtualizací dělám to, co podle vás dělat nejde.
K tomu jenom připomenu, že už jsme se dříve dopracovali k tomu, že s plnou virtualizací dělám to, co podle vás dělat nejde.
A kde jsou nejaka ta cisla? :)
(btw, nechapu, proc mi furt vykas, potykali jsme si uz parkrat, sice jen online, ale...)
A hlavne, cisla z masiny, kde to tak *realne* bezi, v takove agregaci, jakou my mame *beznou*? Dal bych si priklad, kde to tak provozujes, ze si muzes dovolit porozdavat prostredku tolik, aby to neomezovalo - a spis jeste motivovalo "neco dalsiho tam nahodit, kdyz je prostredku dost".
Protoze o tom to u nas *hodne* je - zdaleka ne kazdy ty prostredky naplno vyuziva, ale kdo chce, ma tu moznost. Chceme podporovat cleny v tom, aby si mohli troufnout "na vic".
To je tak nejak cela myslenka vpsFree... sdilet ten HW "co nejlip, co to jde".
Kdyz si vzpomenu vsechny ty (opravdu zbytecne) flamy, ... borci, zkuste si to tak provozovat. My to tu tak jedeme pres deset let, kazdodenni zkusenost. I s tim, ze jsme lidem zpristupnili to KVM a ve spicce "OpenVZ zanedbalosti a chybejicicho vpsAdminOS" se to zacalo hodne projevovat, protoze lidi chteli provozovat plny Docker bez omezeni - no a tam se pekne ukazalo, jak by asi slo tyhle rozmanite workloady agregovat => temer nijak.
Stejnou vec pustenou dvakrat ve stejne konfiguraci na jednom stroji, aby clovek pohledal... docela bych chtel videt, co se tam vubec muze najit k samepage mergingu, kdyz to maji pod spravou uplne jini lide a maji to fakt v totalne ruznych stavech...
Usetrit i treba 100 GB pameti pomoci KSM zni strasne nelakave, baloonem rozhodne tech dalsich 150 GB nenazeneme tak, aby na tom ty virtualy nebrecely...
A tu ZFS cache musim pripominat? :)) Ja si s tim hitrate nedelam srandu, nase masiny bezi naprostou vetsinu casu z RAM. Ale to na to nejaka ta pamet musi byt k dispozici, ze...
A co teprv ten agregacni pomer, kdyz tu masinu zvetsime jeste 4x... To nebude potom o +- 100 virtualech na 256G RAM, kde kazdy ma prideleno 4GB, myslim, ze s prehledem pujdeme na nejakey 5ti nasobek. A jeste budeme moct to maximum zvednout na 6 GB... *vsem* na tom stroji...
Kdyz tomu tak moc veris, jdi, postav to a predved to funkcni ;)
Ja jsem si mezitim vicemene na beton jisty, ze nam nezbyva nic jineho, nez ve vyvoji vpsAdminOS pokracovat. Kontejnery jsou totiz to, co vubec cele vpsFree umoznuje, tak, jak to ted existuje a funguje. Ale rad se necham vyvest z omylu!
Dokonce, velmi, velmi rad uvitam, kdyz nekdo pujde a udela treba nejake to kvmFree a ukaze, ze to jde delat cele uplne jinak, ze my se tady morime s cimsi uplne, ale totalne zbytecne ;)
/snajpa
On 16. 08. 20 10:50, Pavel Snajdr wrote:
K tomu jenom připomenu, že už jsme se dříve dopracovali k tomu, že s plnou virtualizací dělám to, co podle vás dělat nejde.
A kde jsou nejaka ta cisla? :)
Hledat tu debatu (a ta čísla v ní) nebudu, je to pár let zpátky. (A mám pocit, že to tenkrát nebylo o paměti, ale o procesorech.)
Kdyz si vzpomenu vsechny ty (opravdu zbytecne) flamy, ... borci, zkuste si to tak provozovat. My to tu tak jedeme pres deset let, kazdodenni zkusenost. I s tim, ze jsme lidem zpristupnili to KVM a ve spicce "OpenVZ zanedbalosti a chybejicicho vpsAdminOS" se to zacalo hodne projevovat, protoze lidi chteli provozovat plny Docker bez omezeni - no a tam se pekne ukazalo, jak by asi slo tyhle rozmanite workloady agregovat => temer nijak.
Tohle se nedá srovnávat. Tohle je případ, ve kterém je to KVM provozováno způsobem, jak nejblběji je to možné. Žádné KSM (hádám), žádný monitoring z hostitele. To pak není překvapení, že za téhle situace se to nechová dobře.
Jestli to na něco ukazuje, tak na to, jak to s tou agregací na dvojnásobek fyzické RAM je, konkrétně jak moc závisí na tom, že lze jednotlivým (neaktivním nebo málo aktivním) VM snadno "odebrat cache", aniž by se to hned poznalo. Jakmile se ta cache schovala do toho KVM a stala se z ní aplikační paměť - tedy jakmile členové začali víc využívat to, co mají "slíbené" - přestalo to vycházet tak snadno.
Tj. je potřeba brát do úvahy to, že takhle dobrá agregace není nutně zásluhou jenom použité technologie, ale také způsobu, jakým uživatelé svoje VM využívají.
Kdyz tomu tak moc veris, jdi, postav to a predved to funkcni ;)
Jak jsem psal, pracujeme s tím, že paměť je klientů a nehrabe se jim na ni. A že bych to chtěl programovat jen tak ve volném čase, abych to mohl obenchmarkovat a strčit do šuplíku, to se mi teda nechce.
Jestli to na něco ukazuje, tak na to, jak to s tou agregací na dvojnásobek fyzické RAM je, konkrétně jak moc závisí na tom, že lze jednotlivým (neaktivním nebo málo aktivním) VM snadno "odebrat cache", aniž by se to hned poznalo. Jakmile se ta cache schovala do toho KVM a stala se z ní aplikační paměť - tedy jakmile členové začali víc využívat to, co mají "slíbené" - přestalo to vycházet tak snadno.
Kdybys do toho prestal furt projektovat, jak je to cely spatny a jak nam to nefunguje, to by bylo skvely ;)
Protoze on s tim ten "problem" nebyl, ze by _dosla_ pamet (obzvlast kdyz to dela na pomery rozhodne ne kazdy, ale jen tak kazdy treti, to ani nema jak dojit pamet). Jen se na tom krasne projevilo, jak pak je uzasne smysluplne ta RAM vyuzita. Cili koleckem zpatky porad u toho, co rikam - ze KVM placa pameti.
Naalokovat hordu neceho, co je vyuzite pak naprosto suboptimalne - well... ano, klidne, ale v totalne jinych nakladovych relacich (+ efekt, ze neni videt bezici malware, tedy napr. i potreba mit na takove veci navic CPU, i kdyz se pali *zbytecne*, naopak to jeste skodi ruznym adminum po netu).
/snajpa
On 17. 08. 20 13:16, Pavel Snajdr wrote:
Jestli to na něco ukazuje, tak na to, jak to s tou agregací na dvojnásobek fyzické RAM je, konkrétně jak moc závisí na tom, že lze jednotlivým (neaktivním nebo málo aktivním) VM snadno "odebrat cache", aniž by se to hned poznalo. Jakmile se ta cache schovala do toho KVM a stala se z ní aplikační paměť - tedy jakmile členové začali víc využívat to, co mají "slíbené" - přestalo to vycházet tak snadno.
Kdybys do toho prestal furt projektovat, jak je to cely spatny a jak nam to nefunguje, to by bylo skvely ;)
S dovolením nebudu odpovídat na reakce na něco, co jsem nenapsal.
Jak komu :-) , já to radši zavřu do plnotučného virtuálu a tohle všechno se rázem vyřeší samo z principu.
Používám Proxmox - na kontejnerech se mi líbí to, že po prvním spuštění berou asi 20 MB RAM a ne stovky, jako KVM. Další věc - můžu se jednoduše přepnout do konzole v kontejneru a cokoli tam provést. Podobně mohu upravit jakýkoli soubor přímo (protože to jsou soubory a ne "disk"). Nakonec i ta instalace je jednodušší.
David
-----Original Message----- From: Community-list community-list-bounces@lists.vpsfree.cz On Behalf Of Jirka Bourek Sent: Friday, August 14, 2020 3:08 PM To: community-list@lists.vpsfree.cz Subject: Re: [vpsFree.cz: community-list] Sprava pameti na vpsAdminOS
- Lidem by se libila kontejnerizace od jakziva, ale to by ji Linux
musel umet.
Jak komu :-) , já to radši zavřu do plnotučného virtuálu a tohle všechno se rázem vyřeší samo z principu. I když taky jsem už podlehl a spouštím si doma přes LXC popelnici na Steam. :-)
Jinak v soucasne dobe se kontejnerizaci v jadre venuje jen par premotivovanych lidi z Canonicalu, kteri ale nepremysli nad vecma koncepcne, oni jsou na tom jeste hur - pro ne primarne existuji quick hacky jako defaultni modus operandi, ne ze by jako my "nestihali". Treba takovy Chris Brauner, jeho prace je vylozene bezkoncepcni hura-styl - ono to asi s vanilla linuxem jinak nejde.
Tady bych si teda trochu rejpnul, protože hned to první řešení "prostě nebudeme účtovat mapovanou paměť do memcg členů" je přesně takový quick hack (a upřímně jsem docela čekal to, co je popsané hned o pár řádků níž - že to udělá bordel někde jinde)
Proto se ujala driv a rozsirila tak moc... ne ze by slo o nejakou uzasnou security navic nebo tak (nakonec se ukazuje ve svetle Spectre a podobnych zranitelnosti, ze to borci s tim tvrzenim, ze je fullvirt bezpecnejsi, dost nabubrele prehaneli).
To je hodně zavádějící argument, kontejnery na Spectre a podobné trpí úplně stejně jako plná virtualizace. Takže pro porovnávání zbývá jen to ostatní a tam je na tom plná virtualizace pořád líp. _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj, na VPSce, kterou mám od klienta ve správě se změna neprojevila - zase mám zabrané přes 1 GB paměti přitom, že procesy tolik nežerou - viz screen v příloze. Podle administrace běží na node16.prg
Ahoj, Filip Bartmann
čt 13. 8. 2020 v 13:02 odesílatel Pavel Snajdr snajpa@snajpa.net napsal:
Ahojte,
sliboval jsem (vetsinou off-list), ze shnu pak resenici s pameti na vpsAdminOS, tak tady to je :)
Kdyz chce programator dneska z aplikace pracovat s velkym souborem, je docela rozsirenym pristupem, si takovy soubor namapovat do pameti pomoci mmap(2) syscallu.
To zpusobi, ze se soubor ocitne ve virtualnim pametovem prostoru procesu, tj. ten program si pak muze sahat do toho souboru prostym pristupovanim do pameti (nabizi se teda snadny ukladani napr. Cckovych structu do souboru, pristup pres pointerovou aritmetiku, atd.).
Linux cachuje takovy napamovany soubor po strankach, protoze samotnou pamet spravuje po strankach (1 stranka pameti je na x64 velka 4 kB, huge pages jsou potom dalsi extra story na jindy...). Jakmile aplikace chce precist nejaka data, Linux na pozadi, pokud uz to neudelal, pro ta data alokuje stranku fyzicke pameti, aby ta data mela realne, kde sedet, precte je do te stranky z disku (nebo kde ten soubor je) a pak tu stranku namapuje do prislusneho mista virtualniho pametoveho prostoru naseho procesu, ktery ta data cte.
Jadro vede mapovane stranky v evidenci pomoci LRU listu, coz je datova struktura, seznam, ktery se vyznacuje tim, ze vede v evidenci, ktera polozka byla pouzita naposled (tak, ze se meni pri jejim pouziti jeji poradi na zacatek seznamu).
Kdyz vsechno funguje jak ma, v realne fyzicke pameti jsou pouzivana ctena data a jeste nezapsane "pospinene" (dirty) stranky, do kterych se psalo, tj. je u nich naplanovano, aby se co nejrychleji dostaly na disk (pokud teda cely soubor nebyl otevreny s flagem O_SYNC, nebo podobne, co by vynutilo kazdou zmenu zapsat na disk ihned, nez Linux vrati kontrolu aplikaci pri tom zapisu do mapovaneho souboru; to neni tak caste a to je nam ted "jedno").
Zapis je nastesti vyreseny dobre, Linux ma na to mechanismus, kteremu rika "writeback throttle"; kdyz detekuje, ze se zacina RAM plnit vic, nez je zdravo, zacne aplikaci ty zapisujici pristupy adekvatne zpomalovat. Tohle "impedancni prizpusobeni" funguje vcelku dobre, navic funguje dostatecne dobre i pod memory cgroup.
Memory cgroup je mechanismus, kterym omezujeme pridelenou pamet kontejnerum pod Linuxem - je to volitelna sada dalsich pocitadel vyuziti pameti, nad zakladni systemove, plus vydeleni ukazatelu na LRU, writeback a dalsi cache, aby se dalo pekne vest takovehle seznamy stranek v oddelene, mimojine aby bylo jasne, co komu patri, kdyz dojde cas tu pamet jednou odklidit. Ale taky, aby se dalo hlidat maximalni vyuziti pameti na ruzne caches - zdaleka nejen - kvuli prave mapovanym souborum.
Potud vsechno dobre.
To nam tak system nabehne, pospousti se na nem stovka VPSek, vsechny aplikace se krasne rozbehnou, nektere si namapujou soubory, nektere do nich vesele zapisuji data...
System muze bezet klidne mesice bez problemu, vsechno stiha, v pohode. Ty seznamy jsou bezne docela kratke, takze sbirka jadernych threadu "kswapd" je na pozadi pekne stiha prochazet a odklizet, jak se postupne nektere memory cgroupy dostavaji s pameti do uzkych.
Koneckoncu, 4 GB RAM (na jeden kontejner) prelozeno na 4 kB stranky znamena teoretickou maximalni delku jednoho seznamu 1M polozek. To se na 2+ gigahertzovych CPU preci stihne projit rychle, ze.
No a pak se stane, ze po treba dvou mesicich behu systemu najednou zoufaly clen pise, ze mu v kontejneru dochazi pamet, pritom at pocita, jak pocita, nemuze se dopocitat, ze by to zabiraly aplikace - je videt, ze je to tim, ze caches nechteji odcouvavat.
Hm, docela spatenka, jak to mame opravit, kdyz to trva tak dlouho, nez se problem projevi? :-D
Tady nekde bych mel podotknout, ze abych byl schopny to takhle pekne vysvetlit, musel jsem doprojit celou cestu do vyresena, takze ted se to jevi zpetne jako trivka, ale nez jsem prisel na to, z ktere strany ten problem pujde aspon nejak resit...
Kdyz se clovek na takovy trpici system prihlasi, vidi tam zpravidla kswapd0 na 100% a kdyz ma ta masina dva fyzicke CPU, tak tam vidi vetsinou i kswapd1 v tom samem stavu.
V dmesgu jsou videt out of memory hlasky z jednotlivych kontejneru, jak narazeji na neodkliditelne caches a jadro zoufale zabiji stare procesy, aby udelalo misto pro dalsi.
V tech OOM hlaskach je videt pokazde i stack trace, odkud ta OOM udalost z jadra prisla - vetsina z nich byla vyvolana kvuli cteni do mmaped souboru, coz se pozna tak, ze v tom stacku jsou videt funkce pridavajici LRU stranky na seznam te memory cgroupe.
Tak si rikam, hm, to ma preci snadne reseni, nebudeme uctovat mapovanou pamet do memory cgroup clenu, ale nechame ji v root memory cgroup...
Okay, to by mohlo fungovat, ze?
..a zase, kswapd0/1 na 100%...
To uz jsem se zacal seriozneji zajimat, co se to vlastne deje, co delaji tak dlouho a jak to cele funguje, kdyz to neslo smaznout "izy hackem".
Napad to byl dobry, fungoval by, nebyt mensi drobnosti:
kswapd, kdyz odklizeji caches na pozadi, prohledavaji memory cgroupy stylem "dej mi takovou, ktera zere nejvic a tu odklidime, kdyz to nebude stacit, pujdem na dalsi".
Tj. pokud se objevi jedna cgroup, ktera je vetsi a ma toho vzdycky vic k odklizeni, muze se vzdycky kswapd zahojit na ni a k dalsim se ani nedostat.
Jedine, kdy se odklizi pamet uplne primo z te memory cgroupy, je tzv. "direct reclaim", cesta kodu primo v momente, kdy je potreba alokovat - ale v tu chvili neni tolik casu na uklizeni, tak se jadro zas tak nesnazi a nekdy to muze vzdat predcasne a rict, ze pamet nenaslo a vyvola OOM situaci v postizene memory cgroupe.
Hmm... okay, takhle by to neslo, tak zkusme mmaped pamet neuctovat cgroupam vubec a nechme ji v zakladnich systemovych seznamech...
A po trochu zapaseni, bo se v jadre s memory cgroup nepocita, ze by nahodou mmaped pamet nebyla uctovana zadne memory cgroupe, je vyreseno, odchod na parek!
...do chvile, nez tim posleme celou masinu out-of-memory a OOM chyby zacnou prichazet odkudkoliv, ne jen z mmaped readu odzpod z mem-cgroup...
Totiz kdyz byly mmaped soubory uctovany na jeden seznam, ktery neni v memory cgroupe, myslelo si jadro, ze ma hodne volnou ruku v tom, co si muze dovolit nechat nacachovane - ale v tom je potom mensi caveat se ZFS... postupny nahodny random access pattern k datum mmaped souboru nadela z ARC slab caches fragmentovane reseto, jeste kdyz se drzi ty kousky z tech puvodne nactenych dat pri zivote "pripinovanim" na jeden velky seznam, ktery nema duvod couvat, protoze host ma preci vsechnu pamet k dispozici bez limitu :D
No pak a chudaci kswapd, kdyz si s tim bordelem maji nejak poradit a odklidit to, *obzvlast* kdyz jsou jen dva a kdyz pod nima mame (konecne spravne nastavene se spravnym ashiftem) NVMe pole... na te staging node (nyni node1.stg) se tak darilo zaplnit RAM az skoro do mrtva.
Takze co s tim? :)
Snadna reseni dosla, bude potreba odklizet ty seznamy per-limitovana-memory-cgroup.
Na nekolik iteraci jsem nakonec dospel k patchi, ktery spusti per-NUMA-node "ksoftlimd" thready, pro kazdou memory cgroupu, ktera ma nastaveny soft_limit.
Ksoftlimd pak dela presne toto - prochazi seznamy svoji memory cgroupy a drzi si je okolo soft_limitu.
Kswapd maji o praci s memory cgroupama min, pokud je jadro nastavene v rezimu, ze ma ksoftlimd poustet automaticky (da se tez spoustet jen rucne).
My jsme zatim defaultne zvolili soft_limit jako watermark, nad ktery se ma ksoftlimd snazit vic odklizet, nastavujeme ho na 80% pameti kontejneru - ale do budoucna mozna tohle jeste predelam na nejakou vetsi automatiku, podle toho, jak kde se ukazou pripadne nedostatky.
Tedy, vysledna situace je, ze pokud aplikace zerou min, jak 80% pameti, ale je co drzet v RAM jako cache, bude mit kontejner vyuzito okolo tech 80% - bude to videt normalne jako aplikacni pamet a zbytek jako caches. Uz by se nemelo stat, ze vyuziti stoupne az ke 100% kvuli caches a ze dojde k OOM a zabijeni procesu.
Zaverem bych jeste zminil ty patche:
Pokus mmaped soubory nauctovat root mem cgroupe:
https://github.com/vpsfreecz/linux/commit/d42232f89795
Pokus mmaped soubory mem cgroupam neuctovat vubec (popis commitu je blbe a celkove je nedocisteny, nebyl jsem s tim spokojeny a nechtel jsem tim travit vic casu, radsi jsem koumal, co dal, at the time...) ->
https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95
A finalne, aktualne nasazena verze ksoftlimd patche:
https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d
A uplne-uplne zaverem: linux kernel neni advanced black magic. Je to jen strasne velka a nekdy dost neforemna kupa C kodu, ktery potrebuje schopne a ochotne instalatery.
V koncinach memory cgroup + memory managementu je teda hodne, co zlepsovat, a vubec to neni raketova veda... Teda obecne, na kontejnerizace v Linuxu je dost co resit.
Takze kdybyste s tim jadernym vyvojem nekdo chtel pomoct, stavte se na IRC, nebo v Base48 v Brne pokecat, neco vymyslime, bude to zabava, trust me ;)
/snajpa _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj,
a to je obecne nejaky problem? ;)
Pres 1 GB bys mel zabrane normalne, at to bude, kde to bude, protoze caches... tady uctujeme jen dost maly subset z tech caches, navic to umi odcouvat, az je potreba.
Btw, naopak ja vidim problem v tom, ze nechavas MySQL v defaultu, tj. na realnem systemu bez ZFS bys mel jeste k tomu v tehle konfiguraci vykonnostni problemy, at to ma RAM, kolik chce.
"Vyuzita" RAM temahle caches muze vystoupat az na 80% maxima a porad to bude v poradku.
Problem nastane, pokud prichazeji OOM killy a pritom by mela byt volna pamet.
/snajpa
On 2020-08-21 14:28, Filip Bartmann wrote:
Ahoj, na VPSce, kterou mám od klienta ve správě se změna neprojevila - zase mám zabrané přes 1 GB paměti přitom, že procesy tolik nežerou - viz screen v příloze. Podle administrace běží na
node16.prgAhoj, Filip Bartmann
čt 13. 8. 2020 v 13:02 odesílatel Pavel Snajdr snajpa@snajpa.net napsal:
Ahojte,
sliboval jsem (vetsinou off-list), ze shnu pak resenici s pameti na
vpsAdminOS, tak tady to je :)
Kdyz chce programator dneska z aplikace pracovat s velkym souborem, je docela rozsirenym pristupem, si takovy soubor namapovat do pameti pomoci mmap(2) syscallu.
To zpusobi, ze se soubor ocitne ve virtualnim pametovem prostoru procesu, tj. ten program si pak muze sahat do toho souboru prostym pristupovanim do pameti (nabizi se teda snadny ukladani napr. Cckovych structu do souboru, pristup pres pointerovou aritmetiku, atd.).
Linux cachuje takovy napamovany soubor po strankach, protoze samotnou pamet spravuje po strankach (1 stranka pameti je na x64 velka 4 kB, huge pages jsou potom dalsi extra story na jindy...). Jakmile aplikace chce precist nejaka data, Linux na pozadi, pokud uz to neudelal, pro ta data alokuje stranku fyzicke pameti, aby ta data mela realne, kde sedet,
precte je do te stranky z disku (nebo kde ten soubor je) a pak tu stranku namapuje do prislusneho mista virtualniho pametoveho prostoru naseho procesu, ktery ta data cte.
Jadro vede mapovane stranky v evidenci pomoci LRU listu, coz je datova struktura, seznam, ktery se vyznacuje tim, ze vede v evidenci, ktera polozka byla pouzita naposled (tak, ze se meni pri jejim pouziti jeji poradi na zacatek seznamu).
Kdyz vsechno funguje jak ma, v realne fyzicke pameti jsou pouzivana
ctena data a jeste nezapsane "pospinene" (dirty) stranky, do kterych se psalo, tj. je u nich naplanovano, aby se co nejrychleji dostaly na disk (pokud teda cely soubor nebyl otevreny s flagem O_SYNC, nebo podobne, co by vynutilo kazdou zmenu zapsat na disk ihned, nez Linux vrati kontrolu aplikaci pri tom zapisu do mapovaneho souboru; to neni tak caste a to je nam ted "jedno").
Zapis je nastesti vyreseny dobre, Linux ma na to mechanismus, kteremu rika "writeback throttle"; kdyz detekuje, ze se zacina RAM plnit vic, nez je zdravo, zacne aplikaci ty zapisujici pristupy adekvatne zpomalovat. Tohle "impedancni prizpusobeni" funguje vcelku dobre, navic funguje dostatecne dobre i pod memory cgroup.
Memory cgroup je mechanismus, kterym omezujeme pridelenou pamet kontejnerum pod Linuxem - je to volitelna sada dalsich pocitadel vyuziti pameti, nad zakladni systemove, plus vydeleni ukazatelu na LRU, writeback a dalsi cache, aby se dalo pekne vest takovehle seznamy stranek v oddelene, mimojine aby bylo jasne, co komu patri, kdyz dojde cas tu pamet jednou odklidit. Ale taky, aby se dalo hlidat maximalni vyuziti pameti na ruzne caches - zdaleka nejen - kvuli prave mapovanym souborum.
Potud vsechno dobre.
To nam tak system nabehne, pospousti se na nem stovka VPSek, vsechny aplikace se krasne rozbehnou, nektere si namapujou soubory, nektere do nich vesele zapisuji data...
System muze bezet klidne mesice bez problemu, vsechno stiha, v pohode. Ty seznamy jsou bezne docela kratke, takze sbirka jadernych threadu
"kswapd" je na pozadi pekne stiha prochazet a odklizet, jak se postupne nektere memory cgroupy dostavaji s pameti do uzkych.
Koneckoncu, 4 GB RAM (na jeden kontejner) prelozeno na 4 kB stranky
znamena teoretickou maximalni delku jednoho seznamu 1M polozek. To se na 2+ gigahertzovych CPU preci stihne projit rychle, ze.
No a pak se stane, ze po treba dvou mesicich behu systemu najednou zoufaly clen pise, ze mu v kontejneru dochazi pamet, pritom at pocita, jak pocita, nemuze se dopocitat, ze by to zabiraly aplikace - je videt, ze je to tim, ze caches nechteji odcouvavat.
Hm, docela spatenka, jak to mame opravit, kdyz to trva tak dlouho, nez se problem projevi? :-D
Tady nekde bych mel podotknout, ze abych byl schopny to takhle pekne vysvetlit, musel jsem doprojit celou cestu do vyresena, takze ted se to jevi zpetne jako trivka, ale nez jsem prisel na to, z ktere strany ten problem pujde aspon nejak resit...
Kdyz se clovek na takovy trpici system prihlasi, vidi tam zpravidla
kswapd0 na 100% a kdyz ma ta masina dva fyzicke CPU, tak tam vidi vetsinou i kswapd1 v tom samem stavu.
V dmesgu jsou videt out of memory hlasky z jednotlivych kontejneru, jak narazeji na neodkliditelne caches a jadro zoufale zabiji stare procesy, aby udelalo misto pro dalsi.
V tech OOM hlaskach je videt pokazde i stack trace, odkud ta OOM udalost z jadra prisla - vetsina z nich byla vyvolana kvuli cteni do mmaped
souboru, coz se pozna tak, ze v tom stacku jsou videt funkce pridavajici LRU stranky na seznam te memory cgroupe.
Tak si rikam, hm, to ma preci snadne reseni, nebudeme uctovat mapovanou pamet do memory cgroup clenu, ale nechame ji v root memory cgroup...
Okay, to by mohlo fungovat, ze?
..a zase, kswapd0/1 na 100%...
To uz jsem se zacal seriozneji zajimat, co se to vlastne deje, co delaji tak dlouho a jak to cele funguje, kdyz to neslo smaznout "izy hackem".
Napad to byl dobry, fungoval by, nebyt mensi drobnosti:
kswapd, kdyz odklizeji caches na pozadi, prohledavaji memory cgroupy stylem "dej mi takovou, ktera zere nejvic a tu odklidime, kdyz to nebude stacit, pujdem na dalsi".
Tj. pokud se objevi jedna cgroup, ktera je vetsi a ma toho vzdycky vic k odklizeni, muze se vzdycky kswapd zahojit na ni a k dalsim se ani nedostat.
Jedine, kdy se odklizi pamet uplne primo z te memory cgroupy, je tzv. "direct reclaim", cesta kodu primo v momente, kdy je potreba alokovat - ale v tu chvili neni tolik casu na uklizeni, tak se jadro zas tak nesnazi a nekdy to muze vzdat predcasne a rict, ze pamet nenaslo a vyvola OOM situaci v postizene memory cgroupe.
Hmm... okay, takhle by to neslo, tak zkusme mmaped pamet neuctovat cgroupam vubec a nechme ji v zakladnich systemovych seznamech...
A po trochu zapaseni, bo se v jadre s memory cgroup nepocita, ze by
nahodou mmaped pamet nebyla uctovana zadne memory cgroupe, je vyreseno, odchod na parek!
...do chvile, nez tim posleme celou masinu out-of-memory a OOM chyby zacnou prichazet odkudkoliv, ne jen z mmaped readu odzpod z mem-cgroup...
Totiz kdyz byly mmaped soubory uctovany na jeden seznam, ktery neni v memory cgroupe, myslelo si jadro, ze ma hodne volnou ruku v tom, co si muze dovolit nechat nacachovane - ale v tom je potom mensi caveat se ZFS... postupny nahodny random access pattern k datum mmaped souboru nadela z ARC slab caches fragmentovane reseto, jeste kdyz se drzi ty kousky z tech puvodne nactenych dat pri zivote "pripinovanim" na jeden velky seznam, ktery nema duvod couvat, protoze host ma preci vsechnu pamet k dispozici bez limitu :D
No pak a chudaci kswapd, kdyz si s tim bordelem maji nejak poradit a odklidit to, *obzvlast* kdyz jsou jen dva a kdyz pod nima mame (konecne spravne nastavene se spravnym ashiftem) NVMe pole... na te staging node (nyni node1.stg) se tak darilo zaplnit RAM az skoro do mrtva.
Takze co s tim? :)
Snadna reseni dosla, bude potreba odklizet ty seznamy per-limitovana-memory-cgroup.
Na nekolik iteraci jsem nakonec dospel k patchi, ktery spusti per-NUMA-node "ksoftlimd" thready, pro kazdou memory cgroupu, ktera ma nastaveny soft_limit.
Ksoftlimd pak dela presne toto - prochazi seznamy svoji memory cgroupy a drzi si je okolo soft_limitu.
Kswapd maji o praci s memory cgroupama min, pokud je jadro nastavene v rezimu, ze ma ksoftlimd poustet automaticky (da se tez spoustet jen
rucne).
My jsme zatim defaultne zvolili soft_limit jako watermark, nad ktery se ma ksoftlimd snazit vic odklizet, nastavujeme ho na 80% pameti kontejneru - ale do budoucna mozna tohle jeste predelam na nejakou vetsi automatiku, podle toho, jak kde se ukazou pripadne nedostatky.
Tedy, vysledna situace je, ze pokud aplikace zerou min, jak 80% pameti, ale je co drzet v RAM jako cache, bude mit kontejner vyuzito okolo tech 80% - bude to videt normalne jako aplikacni pamet a zbytek jako caches. Uz by se nemelo stat, ze vyuziti stoupne az ke 100% kvuli caches a ze dojde k OOM a zabijeni procesu.
Zaverem bych jeste zminil ty patche:
Pokus mmaped soubory nauctovat root mem cgroupe:
https://github.com/vpsfreecz/linux/commit/d42232f89795 [1]
Pokus mmaped soubory mem cgroupam neuctovat vubec (popis commitu je blbe a celkove je nedocisteny, nebyl jsem s tim spokojeny a nechtel jsem tim travit vic casu, radsi jsem koumal, co dal, at the time...) ->
https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95 [2]
A finalne, aktualne nasazena verze ksoftlimd patche:
https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d [3]
A uplne-uplne zaverem: linux kernel neni advanced black magic. Je to jen strasne velka a nekdy dost neforemna kupa C kodu, ktery potrebuje schopne a ochotne instalatery.
V koncinach memory cgroup + memory managementu je teda hodne, co zlepsovat, a vubec to neni raketova veda... Teda obecne, na kontejnerizace v Linuxu je dost co resit.
Takze kdybyste s tim jadernym vyvojem nekdo chtel pomoct, stavte se na IRC, nebo v Base48 v Brne pokecat, neco vymyslime, bude to zabava, trust me ;)
/snajpa _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [4]
Links:
[1] https://github.com/vpsfreecz/linux/commit/d42232f89795 [2] https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95 [3] https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d [4] http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
community-list@lists.vpsfree.cz
-
David Česal -
Filip Bartmann -
Jirka Bourek -
Ondrej Beranek -
Pavel Snajdr -
Petr Žitný -
Wolf -
zd nex