Spouštění na tmpfs bude rychlejší pouze v případě, že máte hodně diskových I/O, které nejsou splněny z mezipaměti stránky.
Pokud se I/O čte a soubory jsou již v mezipaměti, tmpfs nebude mít žádný rozdíl.
Pokud je I/O asynchronní zápisy bez vyprázdnění a pracovní zátěž je spíše nárazová než nepřetržitá a je zde dostatek mezipaměti pro zachycení shluku zápisů a zápisy mohou být vyprázdněny na pozadí mezi shluky, tmpfs nebude mít žádný rozdíl.
Pokud není třeba provést žádný vstup/výstup na disku, tmpfs nebude mít žádný rozdíl.
Pokud máte hodně diskových I/O a váš proces je zablokován a čeká, až se úložiště dohoní, běh na tmpfs bude mít obrovský rozdíl. Čím pomalejší jsou vaše disky, tím větší rozdíl to bude, až do bodu, kdy se stanete úzkým hrdlem CPU.
(4) Spustitelný soubor se spouští z kontejneru Docker a spustitelný soubor a všechny zúčastněné soubory jsou ve složce tmpfs vytvořené z kontejneru na „interní“ jednotce (která nezůstává po zastavení kontejneru).
(5) Spustitelný soubor se spouští z kontejneru Docker a spustitelný soubor a všechny zahrnuté soubory jsou v "běžných" složkách na disku.
Kromě Tmpfs (které již byly řešeny) si nevšimnete žádného rozdílu mezi spouštěním spustitelných souborů na hostiteli a z kontejneru Docker. Totéž s úložištěm objemu. Docker běží jak pomocí překryvného souborového systému, tak pravděpodobně existuje velmi malý zásah do výkonu pro překryv, ale hostitel vidí spustitelný soubor spuštěný jako proces, jako kdyby byl spuštěn na hostiteli.
Realisticky by měl existovat téměř nulový nebo nulový rozdíl. Mohou existovat pádné důvody, proč něco takového udělat, ale troufám si tvrdit, že v 99,9 % všech případů je to antioptimalizace.
Normální I/O půjde do mezipaměti a nečisté stránky budou zapisovány asynchronně vláknem jádra. Šířka pásma =rychlost RAM, zpoždění =zpoždění RAM (plus možná několik µs pro tu a tam chybu stránky).
Když systému dojde fyzická RAM, zablokujete (samozřejmě), není jiná cesta. Když nezůstanou žádné stránky, na které byste mohli psát, budete muset počkat, dokud se některé neuvolní. Jinak to nejde.
K vyčerpání paměti RAM však ve vašem konkrétním případě z definice pravděpodobně (ani možné) nedojde. Jinak, pokud existuje skutečná možnost, že vám dojde RAM, myšlenka vytvořit tmpfs by byla v první řadě docela hloupá.
I/O do tmpfs půjde do... mezipaměti. Ano, nyní běží pod jiným názvem, ale ve skutečnosti je to úplně stejné, kvůli jednotnému VM systému. Šířka pásma a zpoždění jsou tedy naprosto stejné (udělte nebo vezměte možná 1% rozdíl kvůli jemnostem souborového systému, které se mohou mírně lišit). Žádný zpětný zápis neprobíhá, ano. Ale koho to zajímá, když vidí, jak by to probíhalo asynchronně, tak jako tak. Naopak, nyní nemáte ten luxus, že by někdo uvolnil špinavé stránky na pozadí, takže pravděpodobnost nárazu do stropu, pokud je to možné, je ve skutečnosti vyšší.
Když systému dojde fyzická RAM, stále zapisujete pouze na stránky mapované v paměti, takže byste to teoreticky měli zvládnout rychleji. V praxi je však stále jen tolik a tolik fyzické paměti RAM a právě vám došla! Jistě, ve vašich tmpfs může být stále místo, ale z nějakého důvodu také potřebujete napsat paměťovou stránku jinak a žádná nezbyla.
Takže jádro musí něco udělat pro udržení chodu systému. Musí to nějak přeskupte své zdroje, aby se problém zmírnil (možná výměna procesu dockeru a celého kontejneru?!). Jádro se bude hodně snažit, ale není to tak, že by umělo kouzlit, musí něco udělat a jeho možnosti jsou omezené. Ještě více, protože jste jí záměrně odebrali obrovské množství stránek, které by jinak mohla volně používat podle potřeby pro jakýkoli účel (včetně žádosti, která musí být doručena právě teď).