Lio*_*ior 8 linux tmpfs docker
在 Linux 上，假设我有一个可执行文件。让我们看两种情况：
(A)可执行文件的很大一部分是磁盘 I/O；
(B)可执行文件不执行任何磁盘 I/O。
对于每种情况A和B，我是否应该期望这两种情况之间的可执行文件的运行时间存在显着差异？
(1)可执行文件和所有涉及的文件都在一个 tmpfs 文件夹（一个 RAM 文件夹）中；
(2)可执行文件和所有涉及的文件都在“常规”磁盘文件夹中。
我还对是否应该期待与 Docker 相关的这三个场景之间存在显着差异感兴趣：
(3)可执行文件从 Docker 容器内运行，并且该可执行文件和所有涉及的文件都在从内部创建的 tmpfs 文件夹中使用docker run -v ...
(4)挂载的磁盘驱动器下的容器可执行文件从 Docker 容器内运行，并且可执行文件和所有涉及的文件都位于从容器内创建的 tmpfs 文件夹中，位于“内部”驱动器（即容器停止后不会持续存在）。
(5)可执行文件从 Docker 容器内运行，并且可执行文件和所有涉及的文件都在“常规”磁盘文件夹中。
我的期望是，一般来说，从 tmpfs 文件夹运行应该更快，主要是在涉及大量磁盘 I/O 时。但我在实践中没有看到这一点，所以我想看看我的期望是否正确。
Gor*_*bić 15
仅当您有大量磁盘 I/O 未从页面缓存完成时，在 tmpfs 上运行才会更快。
如果 I/O 是读取并且文件已经在缓存中，tmpfs 将没有任何区别。
如果 I/O 是没有刷新的异步写入，并且工作负载是突发而不是连续的，并且有足够的缓存来吸收突发写入，并且可以在突发之间的后台刷新写入，则 tmpfs 将没有任何区别。
如果没有要进行的磁盘 I/O，tmpfs 将没有任何区别。
如果您有大量磁盘 I/O 并且您的进程被阻塞 iowaiting for storage 跟上，那么在 tmpfs 上运行将产生巨大的不同。您的磁盘越慢，它产生的差异就越大，直到您成为 CPU 瓶颈的地步。