tmpfsフォルダーから実行されるプログラムの方が高速に実行されると思いますか？ （I / Oあり/なし、Dockerコンテナーの内外）
Linuxでは、実行可能ファイルがあるとします。 2つのケースを見てみましょう。
（A）実行可能ファイルが行うことの大部分はディスクI/Oです。
（B）実行可能ファイルはディスクI/Oを実行しません。
[〜＃〜] a [〜＃〜]および[〜＃〜] b [〜＃〜]の各ケースについて、これら2つのシナリオ間の実行可能ファイルの実行時間？
（1）実行可能ファイルと関連するすべてのファイルはtmpfsフォルダーにあります（a RAMフォルダー）;
（2）実行可能ファイルと関連するすべてのファイルは、「通常の」ディスクフォルダにあります。
また、Dockerに関連して、これらの3つのシナリオの間に大きな違いを期待する必要があるかどうかにも興味があります。
（3）実行可能ファイルはDockerコンテナー内から実行され、実行可能ファイルと関連するすべてのファイルは、コンテナー内から作成されたtmpfsフォルダーにあります。 docker run -v ...
（4）実行可能ファイルはDockerコンテナー内から実行され、実行可能ファイルと関連するすべてのファイルは、コンテナー内の「内部」ドライブの下に作成されたtmpfsフォルダーにあります（コンテナが停止した後も持続しません）。
（5）実行可能ファイルはDockerコンテナー内から実行され、実行可能ファイルと関連するすべてのファイルは「通常の」ディスクフォルダーにあります。
私の期待は、一般的に、tmpfsフォルダーから実行する方が高速であるはずであり、主に多くのディスクI/Oが関与している場合です。しかし、実際にはそうではないので、私の期待が正しいかどうかを確認したいと思います。
Tmpfsでの実行は、ページキャッシュで実行されないディスクI/Oが大量にある場合にのみ高速になります。
I/Oが読み取りで、ファイルが既にキャッシュにある場合、tmpfsは違いを生じません。
I/Oがフラッシュなしの非同期書き込みであり、ワークロードが連続的ではなくバースト的であり、書き込みのバーストを吸収するのに十分なキャッシュがあり、バースト間のバックグラウンドで書き込みをフラッシュできる場合、tmpfsは違いを生じません。
実行するディスクI/Oがない場合、tmpfsは違いを生じません。
大量のディスクI/Oがあり、ストレージが追いつくのを待つためにプロセスがブロックされている場合、tmpfsで実行すると大きな違いが生じます。ディスクの速度が遅いほど、CPUのボトルネックになるところまで、ディスクの違いが大きくなります。
（4）実行可能ファイルはDockerコンテナー内から実行され、実行可能ファイルと関連するすべてのファイルは、コンテナー内から作成されたtmpfsフォルダーの「内部」ドライブ（コンテナーの停止後は保持されません）の下にあります。
（5）実行可能ファイルはDockerコンテナー内から実行され、実行可能ファイルと関連するすべてのファイルは「通常の」ディスクフォルダーにあります。
Tmpfsは別として（すでに対処済み）、ホスト上で実行可能ファイルを実行する場合とDockerコンテナー内から実行する場合の違いに気付くことはありません。ボリュームストレージと同じです。 Dockerはオーバーレイファイルシステムを使用して両方を実行しますが、オーバーレイのvery小さなパフォーマンスヒットがある可能性がありますが、ホスト上で実行された場合と同様に、ホストは実行可能ファイルをプロセスとして実行します。
現実的には、ほぼゼロまたはゼロの差があるはずです。そのようなことをする正当な理由があるかもしれませんが、私はすべての場合の99.9％はあえて反最適化です。
通常のI/Oはバッファキャッシュに送られ、ダーティページはカーネルスレッドによって非同期に書き出されます。帯域幅= RAM速度、遅延= RAM遅延（さらに、あちこちにページ違反が発生した場合は数µs）。
システムが物理RAMを使い果たすと、（明らかに）ブロックします。他に方法はありません。書き込むページが残っていない場合は、一部が解放されるまで待つ必要があります。他に方法はありません。
ただし、RAMが不足することは、特定のケースで発生する可能性が高い（または可能性がない）ことです。そうでなければ、実際にRAMが不足する可能性がある場合、tmpfsを作成するという考えはそもそも馬鹿げているでしょう。
TmpfsへのI/Oは...バッファキャッシュに行きます。はい、現在は別の名前で実行されていますが、VMシステムが統一されているため、実際にはまったく同じです。したがって、帯域幅と遅延はまったく同じです（わずかに異なるファイルシステムの微妙さのために、1％の違いを与えるか、または取る可能性があります）。はい、書き戻しは発生していません。しかし、とにかく非同期でどのように発生するかを気にしている人はいます。逆に、ダーティページをバックグラウンドで解放する贅沢さはなくなったので、可能であれば天井にぶつかる可能性が実際に高くなっています。
システムの物理RAMが不足しても、メモリにマップされているページにのみ書き込みを行っているため、理論的にはそれをより高速に実行できるはずです。ただし、実際には、まだ非常に多くの物理RAMしかなく、不足しているだけです。確かに、tmpfsにはまだ空きがあるかもしれませんが、何らかの理由でalsoでなければメモリページを書き込む必要があり、残りはありません。
したがって、カーネルはシステムを実行し続けるためにsomethingを実行する必要があります。 どういうわけか問題を軽減するためにリソースを再配置する必要があります（おそらくDockerプロセスとコンテナー全体をスワップアウトしますか？！）。カーネルは一生懸命努力しますが、魔法を実行できるようなものではありません。何かを実行する必要があり、その選択肢は限られています。さらに、意図的に膨大な数のページを故意に取り除いたので、それ以外の場合は、目的に応じて必要に応じて自由に使用できます（現時点で提供する必要がある要求を含む）。