Poraďte zajímavé využití RAM disku v Linuxu

[tvojtatko]

Zdravim,

mam 64 GB RAM na mojom desktope a spomenul som si, ze v Linuxe sa da jednoducho spravit z RAM dalsi disk.

Spravil som si skusobne novy mount na 4GB a nastavil som IntelliJ IDEA tak, aby tam bola cache a indexy a je to celkom svizne. PC skoro nikdy nevypinam, len hibernujem. Ak restartnem PC raz do mesiaca tak som ochotny podstupit re-indexaciu pri novom starte. Ten tmpfs do ramky mam vo fstab.

Zaujimali by ma vase aplikacie tejto techniky, takze by som mohol zrychlit takymto sposobom PC este viac.

[Reklama]

[alex6bbc]

ja pouzil ramdisk pro minecrafti server.
ale benchmarky jsem nedelal.

[RDa]

Kdyz obnovuji soubory z disku ci pametovych karet (vlastnimi nastroji, delane na miru danemu fs / vade ktera nastala  /souborum ktere potrebuji zachranit) tak mam pracovni image v /dev/shm - je to o neco sviznejsi nez je mit na Optane, kde je nevolatilni kopie obrazu. V ramce do toho muzu i zapisovat pokud je potreba, obnova do vychoziho stavu je svizna a nekonzumuje prepisy bunek (mam 512GB ram, takze lze pracovat nad obrazy disku do 480GB).

[🇺🇦 cjohn]

Nastav cache prehliadaca (FF, chrome,...) na RAM disk.

[Zdenek Tomes]

Kód: [Vybrat]

sudo mount -t tmpfs -o size=16G myramdisk /tmp/ramdisk
mkdir /tmp/ramdisk/go-build
mkdir /tmp/ramdisk/mozilla
+ je potreba udelat toto:

Kód: [Vybrat]

ls -l .cache/mozilla
lrwxrwxrwx 1 tester tester 20 May 20  2021 .cache/mozilla -> /tmp/ramdisk/mozilla
(a jak vidis, mam tam nastaveny i go buildy, co jsou velky a porad se prepisuji, to na SSD moc nechci)

[Reklama]

[Michal Kubeček]

Pokud máte dost paměti a nepotřebujete v /tmp nic extrémně velkého, je dobré ho mountovat jako tmpfs, např.:

Kód: [Vybrat]

tmpfs                     /tmp          tmpfs  mode=1777,size=8g          0  0
(Ten parametr size je trochu zavádějící, IMHO by se spíš měl jmenovat limit.) Potom mám ještě jeden větší, který používám na prakticky všechny buildy a všechno ostatní, co je potřeba jen na chvíli. Občas ho používám i tak, že tam zkopíruju celý virtuální stroj, který potřebuju na nějaký jednorázový experiment.

Kromě jiného to má výhodu, že není potřeba řešit úklid, nejpozději při příštím rebootu všechno zmizí. A když ho potřebuju vyčistit dřív, stačí odmountovat a přimountovat, u složitějších adresářových struktur to bývá i rychlejší než "rm -r". (Mám na to skript a příslušnou položku v sudoers.) Jen je potřeba, aby tam žádný proces v tu chvíli neměl otevřený soubor nebo pracovní adresář.

[Vít Šesták (v6ak)]

Já se netajím, že nejsem velký fanoušek tmpfs. Má svoje využití, ale často lze podobného efektu dosáhnout i lépe. Kernel umí „volnou“ RAM využívat jako cache pro soubory. Z hlediska čtení tak vlastně může stačit spustit něco jako find /some/dir -print0 | xargs -0 cat > /dev/null, abychom načetli adresář do cache. Případně lze použít ionice, aby se prefetch provedl s co nejnižší prioritou. A asi tu budou i lepší prefetchovací nástroje. (Pamatuju si nějaké, které sloužily spíše pro urychlení bootu – zejména ureadahead.)

Z hlediska zápisu se to samozřejmě tmpfs nevyrovná, zejména pokud něco trvá na syncnutí dat na fyzické úložiště. Ale v případě indexů to možná nebude až takový problém. Šlo by si s tím hrát i více a optimalizovat nastavení FS, aby tolik nehrotil konzistenci, ale čekám:

1. Trochu drbačku,
2. Uvažování nad tím, kde to nevadí jak moc ošulit a
3. Často minimální přínos.

[_Tomáš_]

Já se netajím, že nejsem velký fanoušek tmpfs. Má svoje využití, ale často lze podobného efektu dosáhnout i lépe. Kernel umí „volnou“ RAM využívat jako cache pro soubory. Z hlediska čtení tak vlastně může stačit spustit něco jako find /some/dir -print0 | xargs -0 cat > /dev/null, abychom načetli adresář do cache. Případně lze použít ionice, aby se prefetch provedl s co nejnižší prioritou. A asi tu budou i lepší prefetchovací nástroje. (Pamatuju si nějaké, které sloužily spíše pro urychlení bootu – zejména ureadahead.)

Z hlediska zápisu se to samozřejmě tmpfs nevyrovná, zejména pokud něco trvá na syncnutí dat na fyzické úložiště. Ale v případě indexů to možná nebude až takový problém. Šlo by si s tím hrát i více a optimalizovat nastavení FS, aby tolik nehrotil konzistenci, ale čekám:

1. Trochu drbačku,
2. Uvažování nad tím, kde to nevadí jak moc ošulit a
3. Často minimální přínos.

na tohle roky používám https://hoytech.com/vmtouch/, dokonce to je součástí mnoha produkcí našich bank, v podstatě tim zajištujeme zahřátí dat do paměti, výhoda je, že to transparentní, velice efektivní a plně konfigurovatelné.

Existuje třeba eatmydata(1), který umí přepsat v glibc fsync funkci a pro daný program jí deaktovat, je pak možné nechat persistování na nastavení kernelu, používám na raspberry pi, aby mi programy příliš často nezapisovali na disk, mám přímo glibc patchovaný.

Pokud jde o využití velké paměti, tak jí mám všude vždy nedostatek. U vývojového stroje zásadné vše kompiluji do tmpfs. Na windows mám zase ramdisk na datový složky pro hry (sync z disku při startu os nebo ručně). Rád třeba věci jako zpracování fotek dělám rovnou z tmpfs, to mi nestačí ani 200GB.

[Vít Šesták (v6ak)]

Jo, eatmydata je někdy fajn, ale je nutná opatrnost a znalost, co to vlastně dělá  Někdy bych to chtěl použít spíše na jeden adresář než na celou aplikaci. (Proto jsem zmínil ten FS nakonfigurovaný tak, aby tolik neřešil konzistenci – u ext4 to celkem šlo.) A když to použiju, může být fajn zajistit, že se ta data nepoužijí v případě neslušného vypnutí počítače.

V praxi jsem to používal na DB pro integrační testy. Pokud by došlo k náhlému vypnutí počítače, stejně testy jely od nuly a s čistou DB. Tehdy byla doba, kdy jsem byl rád za nějaké malé 120GB SSD (jako doplněk k HDD) a o NVMe nebyla ani řeč, mám pocit, že šlo o asi dvojnásobné zrychlení, dnes to možná s NVMe SSD nebude tak výrazné, a indexů v IDE bych se na to úplně vykašlal. Ale tam jsem nakonec místo eatmydata použil nějakou konfigurační volbu v PostgreSQL.

Ještě lze něco podobného použít u buildu Dockerových images. IIRC v Dockerových Debianích imagích jsem viděl podobné nastavení pro apt. Na druhou stranu mě tím Docker trošku zklamal – jednak to mohlo fungovat nějak univerzálněji a jednak to mohlo být omezené jen na některé situace (typicky build), v některých edge cases toto chování úplně nechcete.

Filozoficky jsem se inspiroval trochu zde: https://shnatsel.blogspot.com/2012/05/tmpfs-for-real-life-write-buffering.html

[František Ryšánek]

Ještě tu nepadla zmínka o overlayfs nad RO-mounted rootem. Počítač pak funguje a OS si myslí, že zapisuje na disk, dokud nedojde RAMka :-) Používám pro "read-only NFS-root" nebo případně nad flashkou.

Jako kompromisní varianta, pokud třeba chcete flashce ulevit od zbytečných zápisů, se nabízí namountovat do tmpfs jenom některé adresáře - už tu někdo zmínil cache browseru, nebo třeba /var/log.

A jak už tu někdo zmínil, Linux by default používá volnu RAMku svobodně pro diskové buffery (cache). Buffery pro čtená data netřeba tunit, stránkovací mechanismus zcela samozřejmě drží v RAMce všechny načtené stránky, dokud nepotřebuje RAMku pro jiné účely (třeba nějaký proces si chce kus alokovat) - v tom případě nastoupí LRU. A pro zápis lze výrazného efektu často dosáhnout úpravou sysctl proměnných /proc/sys/vm/dirty_ratio, /proc/sys/vm/dirty_background_ratio, /proc/sys/vm/dirty_expire_centisecs . Defaulty jsou zbytečně konzervativní: k čemu je mi 8 GB RAM, když pro diskovou WB cache smí kernel využít třeba jenom 5-10%. Pro mě za mě ať si vezme klidně 80-90%. Třeba kompilaci kernelu nebo instalaci většího počtu balíčků na točivém disku to zrychlí dost citelně. Někdy to pošteluju už v instalátoru na jednotlivém stroji, aby instalace běžela rychleji. Pokud zapisující aplikace nedělá příliš často tvrdý blokující "sync", tak běžných frontovatelných bariérových operací zřejmě generuje filesystém relativně málo...

[Vít Šesták (v6ak)]

Vím, že byla řeč o rotačáku, ale překvapuje mě, že nastavení dirty_* má až takový vliv na rychlost kompilace. I kdybych počítal 5 % z 8G, máme 400M, a to bych čekal, že zápisy při kompilaci vykryje. Možná dirty_expire_centisecs, ale i tam bych intuitivně čekal, že to bude stačit.

[mastnacek]

Lze vytvorit ramdisk na konretnich pametovych modulech?

[Vít Šesták (v6ak)]

Jakože byste chtěl dát ramdisk na konkrétní fyzický modul paměti?

1. Jak to souvisí s vláknem?
2. Proč by to někdo dělal?
3. Asi prakticky moc ne – mj. byste se musel vzdát vícekanálové paměti, jinak se jeho obsah rozdělí mezi více fyzických modulů, aby tam byl přístup rychlejší.
4. Teoreticky je možné leccos, když si k tomu náležitě upravíte zdroják. Hádám, že nikdo tu práci za Vás ještě neudělal, protože neznám odpověď na #2.

[jjrsk]

Lze vytvorit ramdisk na konretnich pametovych modulech?

Na systemovy urovni urcite ne, protoze neznas obecne organizaci ram. Ramka vubec nemusi byt rozdelena po modulech, muze (a typicky taky je) rozdelena tak, ze kdyz mas 2 moduly, tak kazdy druhy blok pameti je v jinem. Takze bys ten ramdisk mel v ramce napreskacku rozdrbanej na hromady bloku. I tak bys musel znat konkretni realizaci na zcela konkretnim HW. A ani to by nestacilo, nejspis bys musel zasadne upravit kernel. Jednoduse proto, ze se ramka virtualizuje.

2Vít Šesták: Treba proto, ze mas ruzne rychly moduly a chtel bys to dat do konkretnich?

[RDa]

2Vít Šesták: Treba proto, ze mas ruzne rychly moduly a chtel bys to dat do konkretnich?

Tohle imho neplati na zadne platforme, dokonce snad ani na dual socket (2S) systemu bios nenakonfiguruje pameti nezavisle pro ruzne sockety, ale vzdy se najde nejhorsi varianta casovani a na tu se vsechno nastavi.

Jediny zpusob jak dosahnout jineho vykonu pro jiny dimm je pouzit optane ve forme dimmek - Intel DCPMM, ale tam si v biosu zvolite ze to chcete mit 100% jako nonvolatile pamet a pak by mel existovat pametovy region ktery teto specialni dimm-ce prislusi. V pripade volby use-as-ram (a ramka je pak L4 cache), se tato nvdimm pak maskuje za regulerni ram a hw resi read-modify-write a cachovani aby to vubec davalo nejaky vykon (ta nv dimm ma jednotky GB/s na rozdil od bezne ram dimm, ktera dava desitky GB/s).