<div dir="ltr"><div dir="ltr"><div>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?</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">pá 14. 8. 2020 v 14:29 odesílatel zd nex <<a href="mailto:zdnexnet@gmail.com">zdnexnet@gmail.com</a>> napsal:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">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 :) <br></div><div>Zdenek.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">pá 14. 8. 2020 v 14:06 odesílatel Petr Žitný <<a href="mailto:petr@zitny.net" target="_blank">petr@zitny.net</a>> napsal:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Cus,<br>
<br>
me to u jednoho klienta taky trapi, narazime presne na to co cca <br>
popisujes. Zejmena u DEV stroju, kde se to dost toci a zaroven je tam <br>
dost velky overcommit na vsech prostredkach. A ano, taky se to deje <br>
nekdy od tak 60 do 120dne uptime, pak uz to vetsinou nevydrzime a <br>
otocime :-)<br>
<br>
Nicmene tenhle problem v LXC je tak 2+roky a trapi nas to teda na LXC & <br>
BTRFS & cgroups.<br>
<br>
--<br>
<br>
Petr Zitny<br>
<br>
Dne 14.08.2020 v 9:12 Pavel Snajdr napsal(a):<br>
> Pokud vim, tak u Proxmoxu celou tu kontejnerovou cast dost utlumili <br>
> prave s tim, jak umrelo OpenVZ jadro - ted to proste nemaji, jak <br>
> navarit lip, nez vsichni ostatni se standardnim Linuxem.<br>
><br>
> Tj. bude je to trapit :)<br>
><br>
> Otazka je, kdo vlastne kde ma potrebu na tech serverech i realne neco <br>
> poustet.<br>
><br>
> Ve spouste firemnich prostredi se nakoupi hromada HW a pak se z toho <br>
> nevyuziva realne ani 1%... takze, ono to "v malem" bude vzdycky jak <br>
> uchodit. Proste prinejhorsim shodis pametove limity uplne, zejo...<br>
><br>
> Kdyz to ma stejne jenom jednoho admina, nebo jeden adminsky tym, co se <br>
> o to stara...<br>
><br>
> /snajpa<br>
><br>
> On 2020-08-14 07:37, zd nex wrote:<br>
>> Dobrá práce, máš můj obdiv.<br>
>><br>
>> Zeptám se myslíš, že v Proxmoxu narazili na podobný problém?<br>
>><br>
>> Přeci jen je to LXC & ZFS a cgroups? Určitě jsou tam aplikace,<br>
>> které také používají mmap, ne? Několikrát jsem četl, že<br>
>> hodně lidí mmap doporučuje ideálně pro velké soubory.<br>
>> např.<br>
>><br>
>> tady <a href="https://blog.askesis.pl/post/2019/02/mmap.html" rel="noreferrer" target="_blank">https://blog.askesis.pl/post/2019/02/mmap.html</a> [5]<br>
>> <a href="https://stackoverflow.com/questions/258091/when-should-i-use-mmap-for-file-access/2895799" rel="noreferrer" target="_blank">https://stackoverflow.com/questions/258091/when-should-i-use-mmap-for-file-access/2895799</a> <br>
>><br>
>> [6]<br>
>><br>
>> Zdenek pripravto<br>
>><br>
>> čt 13. 8. 2020 v 14:22 odesílatel Ondrej Beranek <<a href="mailto:rainbof@gmail.com" target="_blank">rainbof@gmail.com</a>><br>
>> napsal:<br>
>><br>
>>> Poutave vysvetleni, dobra prace diky.<br>
>>><br>
>>> čt 13. 8. 2020 v 13:02 odesílatel Pavel Snajdr <<a href="mailto:snajpa@snajpa.net" target="_blank">snajpa@snajpa.net</a>><br>
>>> napsal:<br>
>>><br>
>>>> Ahojte,<br>
>>>><br>
>>>> sliboval jsem (vetsinou off-list), ze shnu pak resenici s pameti<br>
>>>> na<br>
>>>> vpsAdminOS, tak tady to je :)<br>
>>>><br>
>>>> Kdyz chce programator dneska z aplikace pracovat s velkym<br>
>>>> souborem, je<br>
>>>> docela rozsirenym pristupem, si takovy soubor namapovat do pameti<br>
>>>> pomoci<br>
>>>> mmap(2) syscallu.<br>
>>>><br>
>>>> To zpusobi, ze se soubor ocitne ve virtualnim pametovem prostoru<br>
>>>> procesu, tj. ten program si pak muze sahat do toho souboru<br>
>>>> prostym<br>
>>>> pristupovanim do pameti (nabizi se teda snadny ukladani napr.<br>
>>>> Cckovych<br>
>>>> structu do souboru, pristup pres pointerovou aritmetiku, atd.).<br>
>>>><br>
>>>> Linux cachuje takovy napamovany soubor po strankach, protoze<br>
>>>> samotnou<br>
>>>> pamet spravuje po strankach (1 stranka pameti je na x64 velka 4<br>
>>>> kB, huge<br>
>>>> pages jsou potom dalsi extra story na jindy...). Jakmile aplikace<br>
>>>> chce<br>
>>>> precist nejaka data, Linux na pozadi, pokud uz to neudelal, pro<br>
>>>> ta data<br>
>>>> alokuje stranku fyzicke pameti, aby ta data mela realne, kde<br>
>>>> sedet,<br>
>>>> precte je do te stranky z disku (nebo kde ten soubor je) a pak tu<br>
>>>><br>
>>>> stranku namapuje do prislusneho mista virtualniho pametoveho<br>
>>>> prostoru<br>
>>>> naseho procesu, ktery ta data cte.<br>
>>>><br>
>>>> Jadro vede mapovane stranky v evidenci pomoci LRU listu, coz je<br>
>>>> datova<br>
>>>> struktura, seznam, ktery se vyznacuje tim, ze vede v evidenci,<br>
>>>> ktera<br>
>>>> polozka byla pouzita naposled (tak, ze se meni pri jejim pouziti<br>
>>>> jeji<br>
>>>> poradi na zacatek seznamu).<br>
>>>><br>
>>>> Kdyz vsechno funguje jak ma, v realne fyzicke pameti jsou<br>
>>>> pouzivana<br>
>>>> ctena data a jeste nezapsane "pospinene" (dirty) stranky, do<br>
>>>> kterych se<br>
>>>> psalo, tj. je u nich naplanovano, aby se co nejrychleji dostaly<br>
>>>> na disk<br>
>>>> (pokud teda cely soubor nebyl otevreny s flagem O_SYNC, nebo<br>
>>>> podobne, co<br>
>>>> by vynutilo kazdou zmenu zapsat na disk ihned, nez Linux vrati<br>
>>>> kontrolu<br>
>>>> aplikaci pri tom zapisu do mapovaneho souboru; to neni tak caste<br>
>>>> a to je<br>
>>>> nam ted "jedno").<br>
>>>><br>
>>>> Zapis je nastesti vyreseny dobre, Linux ma na to mechanismus,<br>
>>>> kteremu<br>
>>>> rika "writeback throttle"; kdyz detekuje, ze se zacina RAM plnit<br>
>>>> vic,<br>
>>>> nez je zdravo, zacne aplikaci ty zapisujici pristupy adekvatne<br>
>>>> zpomalovat. Tohle "impedancni prizpusobeni" funguje vcelku dobre,<br>
>>>> navic<br>
>>>> funguje dostatecne dobre i pod memory cgroup.<br>
>>>><br>
>>>> Memory cgroup je mechanismus, kterym omezujeme pridelenou pamet<br>
>>>> kontejnerum pod Linuxem - je to volitelna sada dalsich pocitadel<br>
>>>> vyuziti<br>
>>>> pameti, nad zakladni systemove, plus vydeleni ukazatelu na LRU,<br>
>>>> writeback a dalsi cache, aby se dalo pekne vest takovehle seznamy<br>
>>>><br>
>>>> stranek v oddelene, mimojine aby bylo jasne, co komu patri, kdyz<br>
>>>> dojde<br>
>>>> cas tu pamet jednou odklidit. Ale taky, aby se dalo hlidat<br>
>>>> maximalni<br>
>>>> vyuziti pameti na ruzne caches - zdaleka nejen - kvuli prave<br>
>>>> mapovanym<br>
>>>> souborum.<br>
>>>><br>
>>>> Potud vsechno dobre.<br>
>>>><br>
>>>> To nam tak system nabehne, pospousti se na nem stovka VPSek,<br>
>>>> vsechny<br>
>>>> aplikace se krasne rozbehnou, nektere si namapujou soubory,<br>
>>>> nektere do<br>
>>>> nich vesele zapisuji data...<br>
>>>><br>
>>>> System muze bezet klidne mesice bez problemu, vsechno stiha, v<br>
>>>> pohode.<br>
>>>> Ty seznamy jsou bezne docela kratke, takze sbirka jadernych<br>
>>>> threadu<br>
>>>> "kswapd" je na pozadi pekne stiha prochazet a odklizet, jak se<br>
>>>> postupne<br>
>>>> nektere memory cgroupy dostavaji s pameti do uzkych.<br>
>>>><br>
>>>> Koneckoncu, 4 GB RAM (na jeden kontejner) prelozeno na 4 kB<br>
>>>> stranky<br>
>>>> znamena teoretickou maximalni delku jednoho seznamu 1M polozek.<br>
>>>> To se na<br>
>>>> 2+ gigahertzovych CPU preci stihne projit rychle, ze.<br>
>>>><br>
>>>> No a pak se stane, ze po treba dvou mesicich behu systemu<br>
>>>> najednou<br>
>>>> zoufaly clen pise, ze mu v kontejneru dochazi pamet, pritom at<br>
>>>> pocita,<br>
>>>> jak pocita, nemuze se dopocitat, ze by to zabiraly aplikace - je<br>
>>>> videt,<br>
>>>> ze je to tim, ze caches nechteji odcouvavat.<br>
>>>><br>
>>>> Hm, docela spatenka, jak to mame opravit, kdyz to trva tak<br>
>>>> dlouho, nez<br>
>>>> se problem projevi? :-D<br>
>>>><br>
>>>> Tady nekde bych mel podotknout, ze abych byl schopny to takhle<br>
>>>> pekne<br>
>>>> vysvetlit, musel jsem doprojit celou cestu do vyresena, takze ted<br>
>>>> se to<br>
>>>> jevi zpetne jako trivka, ale nez jsem prisel na to, z ktere<br>
>>>> strany ten<br>
>>>> problem pujde aspon nejak resit...<br>
>>>><br>
>>>> Kdyz se clovek na takovy trpici system prihlasi, vidi tam<br>
>>>> zpravidla<br>
>>>> kswapd0 na 100% a kdyz ma ta masina dva fyzicke CPU, tak tam vidi<br>
>>>><br>
>>>> vetsinou i kswapd1 v tom samem stavu.<br>
>>>><br>
>>>> V dmesgu jsou videt out of memory hlasky z jednotlivych<br>
>>>> kontejneru, jak<br>
>>>> narazeji na neodkliditelne caches a jadro zoufale zabiji stare<br>
>>>> procesy,<br>
>>>> aby udelalo misto pro dalsi.<br>
>>>><br>
>>>> V tech OOM hlaskach je videt pokazde i stack trace, odkud ta OOM<br>
>>>> udalost<br>
>>>> z jadra prisla - vetsina z nich byla vyvolana kvuli cteni do<br>
>>>> mmaped<br>
>>>> souboru, coz se pozna tak, ze v tom stacku jsou videt funkce<br>
>>>> pridavajici<br>
>>>> LRU stranky na seznam te memory cgroupe.<br>
>>>><br>
>>>> Tak si rikam, hm, to ma preci snadne reseni, nebudeme uctovat<br>
>>>> mapovanou<br>
>>>> pamet do memory cgroup clenu, ale nechame ji v root memory<br>
>>>> cgroup...<br>
>>>><br>
>>>> Okay, to by mohlo fungovat, ze?<br>
>>>><br>
>>>> ..a zase, kswapd0/1 na 100%...<br>
>>>><br>
>>>> To uz jsem se zacal seriozneji zajimat, co se to vlastne deje, co<br>
>>>> delaji<br>
>>>> tak dlouho a jak to cele funguje, kdyz to neslo smaznout "izy<br>
>>>> hackem".<br>
>>>><br>
>>>> Napad to byl dobry, fungoval by, nebyt mensi drobnosti:<br>
>>>><br>
>>>> kswapd, kdyz odklizeji caches na pozadi, prohledavaji memory<br>
>>>> cgroupy<br>
>>>> stylem "dej mi takovou, ktera zere nejvic a tu odklidime, kdyz to<br>
>>>> nebude<br>
>>>> stacit, pujdem na dalsi".<br>
>>>><br>
>>>> Tj. pokud se objevi jedna cgroup, ktera je vetsi a ma toho<br>
>>>> vzdycky vic k<br>
>>>> odklizeni, muze se vzdycky kswapd zahojit na ni a k dalsim se ani<br>
>>>><br>
>>>> nedostat.<br>
>>>><br>
>>>> Jedine, kdy se odklizi pamet uplne primo z te memory cgroupy, je<br>
>>>> tzv.<br>
>>>> "direct reclaim", cesta kodu primo v momente, kdy je potreba<br>
>>>> alokovat -<br>
>>>> ale v tu chvili neni tolik casu na uklizeni, tak se jadro zas tak<br>
>>>><br>
>>>> nesnazi a nekdy to muze vzdat predcasne a rict, ze pamet nenaslo<br>
>>>> a<br>
>>>> vyvola OOM situaci v postizene memory cgroupe.<br>
>>>><br>
>>>> Hmm... okay, takhle by to neslo, tak zkusme mmaped pamet<br>
>>>> neuctovat<br>
>>>> cgroupam vubec a nechme ji v zakladnich systemovych seznamech...<br>
>>>><br>
>>>> A po trochu zapaseni, bo se v jadre s memory cgroup nepocita, ze<br>
>>>> by<br>
>>>> nahodou mmaped pamet nebyla uctovana zadne memory cgroupe, je<br>
>>>> vyreseno,<br>
>>>> odchod na parek!<br>
>>>><br>
>>>> ...do chvile, nez tim posleme celou masinu out-of-memory a OOM<br>
>>>> chyby<br>
>>>> zacnou prichazet odkudkoliv, ne jen z mmaped readu odzpod z<br>
>>>> mem-cgroup...<br>
>>>><br>
>>>> Totiz kdyz byly mmaped soubory uctovany na jeden seznam, ktery<br>
>>>> neni v<br>
>>>> memory cgroupe, myslelo si jadro, ze ma hodne volnou ruku v tom,<br>
>>>> co si<br>
>>>> muze dovolit nechat nacachovane - ale v tom je potom mensi caveat<br>
>>>> se<br>
>>>> ZFS... postupny nahodny random access pattern k datum mmaped<br>
>>>> souboru<br>
>>>> nadela z ARC slab caches fragmentovane reseto, jeste kdyz se drzi<br>
>>>> ty<br>
>>>> kousky z tech puvodne nactenych dat pri zivote "pripinovanim" na<br>
>>>> jeden<br>
>>>> velky seznam, ktery nema duvod couvat, protoze host ma preci<br>
>>>> vsechnu<br>
>>>> pamet k dispozici bez limitu :D<br>
>>>><br>
>>>> No pak a chudaci kswapd, kdyz si s tim bordelem maji nejak<br>
>>>> poradit a<br>
>>>> odklidit to, *obzvlast* kdyz jsou jen dva a kdyz pod nima mame<br>
>>>> (konecne<br>
>>>> spravne nastavene se spravnym ashiftem) NVMe pole... na te<br>
>>>> staging node<br>
>>>> (nyni node1.stg) se tak darilo zaplnit RAM az skoro do mrtva.<br>
>>>><br>
>>>> Takze co s tim? :)<br>
>>>><br>
>>>> Snadna reseni dosla, bude potreba odklizet ty seznamy<br>
>>>> per-limitovana-memory-cgroup.<br>
>>>><br>
>>>> Na nekolik iteraci jsem nakonec dospel k patchi, ktery spusti<br>
>>>> per-NUMA-node "ksoftlimd" thready, pro kazdou memory cgroupu,<br>
>>>> ktera ma<br>
>>>> nastaveny soft_limit.<br>
>>>><br>
>>>> Ksoftlimd pak dela presne toto - prochazi seznamy svoji memory<br>
>>>> cgroupy a<br>
>>>> drzi si je okolo soft_limitu.<br>
>>>><br>
>>>> Kswapd maji o praci s memory cgroupama min, pokud je jadro<br>
>>>> nastavene v<br>
>>>> rezimu, ze ma ksoftlimd poustet automaticky (da se tez spoustet<br>
>>>> jen<br>
>>>> rucne).<br>
>>>><br>
>>>> My jsme zatim defaultne zvolili soft_limit jako watermark, nad<br>
>>>> ktery se<br>
>>>> ma ksoftlimd snazit vic odklizet, nastavujeme ho na 80% pameti<br>
>>>> kontejneru - ale do budoucna mozna tohle jeste predelam na<br>
>>>> nejakou vetsi<br>
>>>> automatiku, podle toho, jak kde se ukazou pripadne nedostatky.<br>
>>>><br>
>>>> Tedy, vysledna situace je, ze pokud aplikace zerou min, jak 80%<br>
>>>> pameti,<br>
>>>> ale je co drzet v RAM jako cache, bude mit kontejner vyuzito<br>
>>>> okolo tech<br>
>>>> 80% - bude to videt normalne jako aplikacni pamet a zbytek jako<br>
>>>> caches.<br>
>>>> Uz by se nemelo stat, ze vyuziti stoupne az ke 100% kvuli caches<br>
>>>> a ze<br>
>>>> dojde k OOM a zabijeni procesu.<br>
>>>><br>
>>>> Zaverem bych jeste zminil ty patche:<br>
>>>><br>
>>>> Pokus mmaped soubory nauctovat root mem cgroupe:<br>
>>>><br>
>>>> <a href="https://github.com/vpsfreecz/linux/commit/d42232f89795" rel="noreferrer" target="_blank">https://github.com/vpsfreecz/linux/commit/d42232f89795</a> [1]<br>
>>>><br>
>>>> Pokus mmaped soubory mem cgroupam neuctovat vubec (popis commitu<br>
>>>> je blbe<br>
>>>> a celkove je nedocisteny, nebyl jsem s tim spokojeny a nechtel<br>
>>>> jsem tim<br>
>>>> travit vic casu, radsi jsem koumal, co dal, at the time...) -><br>
>>>><br>
>>>> <a href="https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95" rel="noreferrer" target="_blank">https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95</a> [2]<br>
>>>><br>
>>>> A finalne, aktualne nasazena verze ksoftlimd patche:<br>
>>>><br>
>>>> <a href="https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d" rel="noreferrer" target="_blank">https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d</a> [3]<br>
>>>><br>
>>>> A uplne-uplne zaverem: linux kernel neni advanced black magic. Je<br>
>>>> to jen<br>
>>>> strasne velka a nekdy dost neforemna kupa C kodu, ktery potrebuje<br>
>>>><br>
>>>> schopne a ochotne instalatery.<br>
>>>><br>
>>>> V koncinach memory cgroup + memory managementu je teda hodne, co<br>
>>>> zlepsovat, a vubec to neni raketova veda... Teda obecne, na<br>
>>>> kontejnerizace v Linuxu je dost co resit.<br>
>>>><br>
>>>> Takze kdybyste s tim jadernym vyvojem nekdo chtel pomoct, stavte<br>
>>>> se na<br>
>>>> IRC, nebo v Base48 v Brne pokecat, neco vymyslime, bude to<br>
>>>> zabava, trust<br>
>>>> me ;)<br>
>>>><br>
>>>> /snajpa<br>
>>>> _______________________________________________<br>
>>>> Community-list mailing list<br>
>>>> <a href="mailto:Community-list@lists.vpsfree.cz" target="_blank">Community-list@lists.vpsfree.cz</a><br>
>>>> <a href="http://lists.vpsfree.cz/listinfo/community-list" rel="noreferrer" target="_blank">http://lists.vpsfree.cz/listinfo/community-list</a> [4]<br>
>>> _______________________________________________<br>
>>> Community-list mailing list<br>
>>> <a href="mailto:Community-list@lists.vpsfree.cz" target="_blank">Community-list@lists.vpsfree.cz</a><br>
>>> <a href="http://lists.vpsfree.cz/listinfo/community-list" rel="noreferrer" target="_blank">http://lists.vpsfree.cz/listinfo/community-list</a> [4]<br>
>><br>
>><br>
>><br>
>> Links:<br>
>> ------<br>
>> [1] <a href="https://github.com/vpsfreecz/linux/commit/d42232f89795" rel="noreferrer" target="_blank">https://github.com/vpsfreecz/linux/commit/d42232f89795</a><br>
>> [2] <a href="https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95" rel="noreferrer" target="_blank">https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95</a><br>
>> [3] <a href="https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d" rel="noreferrer" target="_blank">https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d</a><br>
>> [4] <a href="http://lists.vpsfree.cz/listinfo/community-list" rel="noreferrer" target="_blank">http://lists.vpsfree.cz/listinfo/community-list</a><br>
>> [5] <a href="https://blog.askesis.pl/post/2019/02/mmap.html" rel="noreferrer" target="_blank">https://blog.askesis.pl/post/2019/02/mmap.html</a><br>
>> [6]<br>
>> <a href="https://stackoverflow.com/questions/258091/when-should-i-use-mmap-for-file-access/2895799" rel="noreferrer" target="_blank">https://stackoverflow.com/questions/258091/when-should-i-use-mmap-for-file-access/2895799</a> <br>
>><br>
>><br>
>> _______________________________________________<br>
>> Community-list mailing list<br>
>> <a href="mailto:Community-list@lists.vpsfree.cz" target="_blank">Community-list@lists.vpsfree.cz</a><br>
>> <a href="http://lists.vpsfree.cz/listinfo/community-list" rel="noreferrer" target="_blank">http://lists.vpsfree.cz/listinfo/community-list</a><br>
> _______________________________________________<br>
> Community-list mailing list<br>
> <a href="mailto:Community-list@lists.vpsfree.cz" target="_blank">Community-list@lists.vpsfree.cz</a><br>
> <a href="http://lists.vpsfree.cz/listinfo/community-list" rel="noreferrer" target="_blank">http://lists.vpsfree.cz/listinfo/community-list</a><br>
_______________________________________________<br>
Community-list mailing list<br>
<a href="mailto:Community-list@lists.vpsfree.cz" target="_blank">Community-list@lists.vpsfree.cz</a><br>
<a href="http://lists.vpsfree.cz/listinfo/community-list" rel="noreferrer" target="_blank">http://lists.vpsfree.cz/listinfo/community-list</a><br>
</blockquote></div></div></blockquote></div></div>