Názory k článku
Jádro bude mít rychlejší swap
-
Já nedávno zase zápasil s Firefoxem. Na notebooku myslím 16GB nebo 32GB RAM a swap oddíl. Bylo jedno co jsem dělal, swappiness, nastavení paměti Firefoxu, dokonce jsem procesu přes systemd zakázal swapovat. A stejně se mi pořád dělo, že jsem měl zabráno sotva 1/4 RAM, ale ve swapu už smrděly 2GB a Firefox se sotva plazil. Přepnout panel znamenalo přeházet vidlema kupu dat mezi swapem a RAM. A bohužel jsem to nedokázal vyřešit. Na desktopu swap pro jistotu nemám a tam všechno jede perfektně.
-
Tak škoda, že sa toto neobjavilo v jadre keď som mal < 2GB RAM :-)
V době, kdy byl swap potřeba kvůli tomu, že uživatelé měli málo paměti, by asi ta větší spotřeba paměti mohla být problém.
Na druhou stranu by mne docela zajímalo, kolik uživatelů dnes ještě swap opravdu běžně využívá. Tedy opravdu jako swap, ne jako prostor pro suspend to disk.
-
Problém je s memory pages, které jsou copy-on-write. Jinými slovy je stránka použitá vícekrát, a pokud do ní někdo zapíše, tak se mu alokuje nová. Tu novou stránku ovšem musíte mít k dispozici. Ve většině případů ji nebudete potřebovat, ale musíte ji mít připravenou. K téhle situaci vedou některá použití mmap (memory mapped files), použití fork() (řekněme duplikace procesu), nebo typicky unixová sekvence fork-exec, která spustí child process pomocí volání fork(), a ten nahradí sebe sama novým procesem pomocí volání exec(). Ve těchto a dalších případech prostě potřebujete mít připravenou paměť, kterou nejspíš nevyužijete, ale pokud dojde na lámání chleba a nebudete ji mít k dispozici, tak nastane problém.
Ve výsledku pokud máte řekněme 128 GB RAM a vypnutý swap, tak část té RAM sedí rezervovaná pro případ potřeby a nepoužije se. Jste potom ve stejné situaci jako kdybyste měl řekněme 96 nebo 64 GB RAM a zapnutý swap.
Pokud jde o výkon, tak minimálně ve Windows se priorita I/O operací při práci se swapem mění podle urgence situace. Například načtení odswapované stránky paměti interaktivní aplikace má prioritu critical, zápis stránek do swapu "pro strýčka příhodu" (ke kterému v případě spousty volné RAM není moc důvod) má nižší prioritu. Ve výsledku tak používání swapu nemá příliš vlivu na výkon, dokud nevyvstane opravdová potřeba swap využívat.
-
Michal ŠmucrBronzový podporovatel
A tušíte, co je příčina, že to nějak citelně swapuje i v těchto situacích?
Fragmentace paměti, používání hugepages nebo třeba hinting z procesů přes madvise() jako MADV_DONTNEED?
Možná se ptám blbě, ale už dlouho jsem nemusel nic podobného řešit, možná kdysi jsem si někde akorát nastavoval vm.swappiness.. -
využití paměti nad 80 %, vysoká fragmentace. Holt tisíce java a python procesů udělají svoje. Sice jsou jednotlivé části ze shora omezeny paměti, aby na serveru pořád několik GB na provoz zbylo, tak Linux si začíná swapovat příliš brzy a zvyšuje IO a prodlužuje některé procesy. Většinou to řešíme vypnutím swapu úplně, ale to přináší jiné komplikace.
-
Michal ŠmucrBronzový podporovatel
Díky moc, to dává smysl a speciálně v tomhle měřítku na systému s 1,5 TB RAM a ty optimalizace a ladění jsou důležité. Já jsem byl i zvědavý, jestli nemyslíte něco i v duchu toho, co tu bylo zmíněno výš třeba s tím Firefoxem, že je třeba volná víc jak půlka paměti a přesto systém swapuje.
Osobně, co si vzpomínám na systémy, kde bylo relativně vysoké vytížení paměti a už to šlo místy do kelu (swapu), tak jsem u někoho řešil Proxmox server, ale to nebylo až tak mechanismem swapování, ale špičkami v provozu, kdy spolu občas bojovaly ty virtuály a ZFS (tam je to vždycky trochu alchymie, je za daných podmínek větší benefit v jeho větší ARC nebo bufferování ve vrstvách nad tím). Nakonec se to vyřešilo upravením provisioningu na těch virtuálech, upravením limitů ARC a následně rozšířením paměti. -
Jaka je nevyhoda nemit swap v tomto pripade ?
Ja si jenom vsim ze s hodne pameti se poji urcita vleklost.. alokace/dealokace (uprava pagetables) nese dost znatelny overhead. Sice nemame X aplikaci ale treba jedno vlakno vyzadujici desitky GB ram.. tak polechtani stranek na pocatku at se alokuji trva dost dlouho :D
(pro ostatni - zkuste si pustit napr. memtest jako aplikaci.. tam je taky prodleva par vterin na alokaci/dealokaci)
-
kromě toho, že všechny běžné monitorovací nástroje pořád křičí a člověk to musí znovu a znovu odůvodňovat, hlavní problém je asi to riziko, že se špatně nastaví kvóty a dojde k OOM na nevhodném procesu. Stejně tak swap pomáhá odlít procesy, které jen jsou v paměti a nic nedělají, uvolní se tím místo na cache stránek nebo jiné procesy.
-
DannyStříbrný podporovatelA pritom v systemd unitach jde pomoci
OOMScoreAdjustmj. rict, kteryze ten proces je jakoze vic nevhodny. -
nj. ale OOMScoreAdjust platí pouze pro proces, který spoustíš a nikoliv pro jeho děti. To trošku snižuje použitelnost, nemyslíš si? :).
U některých aplikací to lze, ale ne vždy je ve službě pouze jeden proces a jako systémové řešení to tedy je nevhodné, můžeš si takhle vyřešit několik konkrétních služeb.
-
No, jo, jenomže na desktopu tak 95 % lidí nemá tolik paměti ani omylem. Nemluvě o tom, že s těmi 64 GB co tu mám se jádro swapu dotkne zatraceně (i když jen přes zram/zswap) když pustím některé leakující věci. Že je ten software krám je druhá věc ale ten bohužel vyměnit nemohu. A dotknul by se i s dvojnásobkem paměti kdybych ty úlohy prostě velikostně zdvojnásobil (musím je kvůli tomu dělit).
