Kdy mám použít /dev/shm/ a kdy /tmp/?

/dev/shm je souborový systém pro dočasné ukládání souborů, tj. tmpfs, který používá RAM pro záložní úložiště. Může fungovat jako implementace sdílené paměti, která usnadňuje IPC.

Z Wikipedie:

Nedávná sestavení linuxového jádra 2.6 začala nabízet /dev/shm jako sdílenou paměť ve formě ramdisku, konkrétněji jako adresář, do kterého lze zapisovat celý svět, který je uložen v paměti s definovaným limitem v /etc/default/tmpfs. Podpora /dev/shm je v konfiguračním souboru jádra zcela volitelná. Standardně je obsažen v distribucích Fedora i Ubuntu, kde jej nejrozsáhleji využívá aplikace Pulseaudio.

/tmp je umístění pro dočasné soubory, jak je definováno ve standardu Filesystem Hierarchy Standard, který následují téměř všechny distribuce Unix a Linux.

Protože RAM je výrazně rychlejší než diskové úložiště, můžete použít /dev/shm místo /tmp pro zvýšení výkonu, pokud je váš proces náročný na vstup/výstup a široce využívá dočasné soubory.

Odpovědi na vaše otázky:Ne, na /dev/shm se nemůžete vždy spolehnout být přítomen, rozhodně ne na strojích připoutaných k paměti. Měli byste použít /tmp pokud nemáte velmi dobrý důvod pro použití /dev/shm .

Pamatujte, že /tmp může být součástí / souborový systém namísto samostatného připojení, a proto může růst podle potřeby. Velikost /dev/shm je omezena přebytečnou RAM v systému, a proto je pravděpodobnější, že vám v tomto souborovém systému dojde místo.

V sestupném pořadí tmpfs pravděpodobnost:

┌───────────┬──────────────┬────────────────┐
│ /dev/shm  │ always tmpfs │ Linux specific │
├───────────┼──────────────┼────────────────┤
│ /tmp      │ can be tmpfs │ FHS 1.0        │
├───────────┼──────────────┼────────────────┤
│ /var/tmp  │ never tmpfs  │ FHS 1.0        │
└───────────┴──────────────┴────────────────┘

Protože se ptáte na konkrétní tmpfs pro Linux přípojný bod versus přenosně definovaný adresář, který může být tmpfs (v závislosti na vašem systémovém správci a na tom, co je výchozí pro vaši distribuci), vaše otázka má dva aspekty, které ostatní odpovědi zdůrazňují odlišně:

1. Vhodné použití různých adresářů tmp
2. Vhodné použití tmpfs

Vhodné použití různých adresářů tmp

Založeno na prastarém standardu hierarchie souborů a na tom, co o tom říká Systemd.

• V případě pochybností použijte /tmp .
• Použijte /var/tmp pro data, která by měla přetrvávat po restartování.
• Použijte /var/tmp pro velká data, která se nemusí snadno vejít do paměti RAM (za předpokladu, že /var/tmp má více dostupného místa – obvykle spravedlivý předpoklad).
• Použijte /dev/shm pouze jako vedlejší účinek volání shm_open() . Zamýšleným publikem jsou ohraničené vyrovnávací paměti, které jsou donekonečna přepisovány. Toto je tedy pro soubory s dlouhou životností, jejichž obsah je nestálý a není příliš velký.
• Rozhodně nepoužívejte /dev/shm pro spustitelné soubory (jakéhokoli druhu), protože se běžně připojuje noexec .
• Pokud si stále nejste jisti, poskytněte uživateli způsob, jak to přepsat. Pro co nejmenší překvapení udělejte jako mktemp a dodržujte TMPDIR proměnná prostředí.

Kde tmpfs exceluje

Je důležité říci, že tam, kde tmpfs opravdu exceluje, je především skrytí výkonnostní chyby, která je na rotujícím disku bolestně významná. Pokud je tedy oprava možností, jedná se samozřejmě o nevhodné použití tmpfs :

fsync je ne-op na tmpfs. Toto systémové volání říká operačního systému, aby vyprázdnil svou mezipaměť stránek spojenou se souborem, až po vyprázdnění mezipaměti pro zápis příslušného úložného zařízení, a to vše při blokování programu, který jej spustil, v provádění jakéhokoli pokroku – velmi hrubá bariéra zápisu. . Je to nezbytný nástroj v krabici pouze proto, že protokoly úložiště nejsou vytvářeny s ohledem na transakce. A ukládání do mezipaměti je zde především proto, aby umožnilo programům provádět miliony malých zápisů do souboru, aniž by si všimly, jak pomalé je ve skutečnosti zápis na úložné zařízení – veškerý skutečný zápis probíhá asynchronně, nebo dokud fsync je zavoláno, což je jediné místo, kde je výkon zápisu přímo pociťován programem.

Takže pokud zjistíte, že používáte tmpfs (nebo eatmydata) jen k poražení fsync, pak vy (nebo nějaký jiný vývojář v řetězci) děláte něco špatně. Znamená to, že transakce směrem k úložnému zařízení jsou pro váš účel zbytečně jemně zrnité – jste zjevně ochotni přeskočit některé záchranné body kvůli výkonu, protože jste nyní zašli do extrému a sabotovali je všechny – zřídkakdy nejlepší kompromis. Je to také zde v oblasti transakčního výkonu, kde jsou některé z největších výhod SSD – každý SSD, který stojí za to, bude fungovat mimo tento svět ve srovnání s tím, co může mít rotující disk (7200 ot./min =120 Hz, pokud k němu nemá přístup nic jiného). Paměťové karty Flash se v této metrice také značně liší (je to kompromis se sekvenčním výkonem a hodnocení třídy karty SD bere v úvahu pouze to druhé). Dejte si tedy pozor, vývojáři s bleskově rychlými SSD, abyste své uživatele do tohoto případu použití nenutili!

Chcete slyšet směšný příběh? Moje první fsync lekce:Měl jsem práci, která zahrnovala rutinní „upgradování“ hromady databází Sqlite (uchovaných jako testovací případy) na neustále se měnící aktuální formát. "Upgrade" framework by spustil spoustu skriptů, každý by provedl alespoň jednu transakci, aby upgradoval jednu databázi. Samozřejmě jsem své databáze upgradoval paralelně (8 paralelně, protože jsem byl obdařen mohutným 8jádrovým CPU). Ale jak jsem zjistil, nedošlo k žádnému zrychlení paralelizace (spíše mírný hit ), protože proces byl zcela vázán IO. Je zábavné zabalit rámec upgradu do skriptu, který zkopíruje každou databázi do /dev/shm , upgradoval to tam a zkopíroval to zpět na disk byl asi 100krát rychlejší (stále s 8 paralelně). Jako bonus byl počítač použitelný také při upgradu databází.

Kde je tmpfs vhodné

Vhodným použitím tmpfs je vyhnout se zbytečnému zápisu nestálých dat. Efektivní deaktivace zpětného zápisu , jako je nastavení /proc/sys/vm/dirty_writeback_centisecs do nekonečna na běžném souborovém systému.

To má velmi málo společného s výkonem a jeho selhání je mnohem menší problém než zneužívání fsync:Časový limit zpětného zápisu určuje, jak líně se obsah disku aktualizuje po obsahu pagecache, a výchozích 5 sekund je pro počítač dlouhá doba. – aplikace může přepisovat soubor tak často, jak chce, v mezipaměti stránek, ale obsah na disku se aktualizuje pouze jednou za 5 sekund. Tedy pokud to aplikace nevynutí pomocí fsync. Přemýšlejte o tom, kolikrát může aplikace za tuto dobu vytisknout malý soubor, a uvidíte, proč by fsynchronizace každého z nich byla mnohem větším problémem.

S čím vám tmpfs nemohou pomoci

• Výkon čtení. Pokud jsou vaše data horká (což je lepší, pokud uvažujete o jejich ponechání v tmpfs), stejně narazíte na pagecache. Rozdíl je, když nenarazíte na pagecache; v takovém případě přejděte na „Kde tmpfs sux“ níže.
• Soubory s krátkou životností. Mohou žít celý svůj život v mezipaměti stránek (jako špinavé stránky) ještě předtím, než budou vypsány. Pokud to nevynutíte pomocí fsync samozřejmě.

Kde tmpfs sux

Udržování chladu data. Můžete být v pokušení myslet si, že poskytování souborů mimo swap je stejně efektivní jako běžný souborový systém, ale existuje několik důvodů, proč tomu tak není:

• Nejjednodušší důvod:Není nic, co by současná úložná zařízení (ať už na pevném disku nebo flash disku) milovala víc než čtení poměrně sekvenčních souborů úhledně uspořádaných správným souborovým systémem. Výměna ve 4KiB blocích to pravděpodobně nezlepší.
• Skryté náklady:výměna mimo . Stránky Tmpfs jsou špinavé — musí být někde zapsány (k výměně), aby mohly být vyřazeny z mezipaměti stránek, na rozdíl od čistého zálohovaného souboru stránky, které lze okamžitě zahodit. Jedná se o extra penalizaci za zápis na vše ostatní, co soutěží o paměť – ovlivňuje něco jiného v jiném čase než použití těchto stránek tmpfs.

Dobře, tady je realita.

Tmpfs i normální souborový systém jsou mezipaměť na disku.

Soubor tmpfs používá paměť a odkládací prostor jako záložní úložiště souborový systém používá specifickou oblast disku, ani jeden není omezen velikostí, kterou může souborový systém být, je docela možné mít 200 GB tmpfs na počítači s méně než GB RAM, pokud máte dostatek swapspace.

Rozdíl je v tom, kdy se data zapisují na disk. U tmpfs se data zapisují POUZE, když se paměť příliš zaplní nebo je nepravděpodobné, že by se data brzy využila. Většina normálních linuxových souborových systémů OTOH je navržena tak, aby vždy měla na disku více či méně konzistentní sadu dat, takže pokud uživatel vytáhne zástrčku, nepřijde o všechno.

Osobně jsem zvyklý mít operační systémy, které nepadnou, a systémy UPS (např. baterie notebooků), takže si myslím, že souborové systémy ext2/3 jsou příliš paranoidní s jejich 5-10 sekundovým intervalem kontrolních bodů. Souborový systém ext4 je lepší s 10minutovým kontrolním bodem, kromě toho, že zachází s uživatelskými daty jako s druhou třídou a nechrání je. (ext3 je stejný, ale kvůli 5 sekundovému kontrolnímu bodu si toho nevšimnete)

Tento častý kontrolní bod znamená, že se na disk neustále zapisují nepotřebná data, dokonce i pro /tmp.

Takže výsledkem je, že musíte vytvořit odkládací prostor tak velký, jak potřebujete, aby byl váš /tmp (i když musíte vytvořit odkládací soubor) a použít tento prostor k připojení tmpfs požadované velikosti do /tmp.

NIKDY nepoužívejte /dev/shm.

Pokud jej nepoužíváte pro velmi malé (pravděpodobně mmap'd) soubory IPC a nejste si jisti, že existuje (není to standard) a počítač má k dispozici více než dostatek paměti + swapu.