Poutave vysvetleni, dobra prace diky. čt 13. 8. 2020 v 13:02 odesílatel Pavel Snajdr <snajpa(a)snajpa.net> napsal: _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list [4]

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] >

> > [6] > > Zdenek pripravto > > čt 13. 8. 2020 v 14:22 odesílatel Ondrej Beranek <rainbof(a)gmail.com> > napsal: > >> Poutave vysvetleni, dobra prace diky. >> >> čt 13. 8. 2020 v 13:02 odesílatel Pavel Snajdr <snajpa(a)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(a)lists.vpsfree.cz >>> http://lists.vpsfree.cz/listinfo/community-list [4] >> _______________________________________________ >> Community-list mailing list >> Community-list(a)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] >

_______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

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. :-)

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.)

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%)

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.

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.

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.