tmpfs での実行は、ページ キャッシュから満たされないディスク I/O が大量にある場合にのみ高速になります。
I/O が読み取りで、ファイルが既にキャッシュにある場合、tmpfs は違いはありません。
I/O がフラッシュなしの非同期書き込みであり、ワークロードが連続的ではなくバースト的であり、書き込みのバーストを吸収するのに十分なキャッシュがあり、バースト間のバックグラウンドで書き込みをフラッシュできる場合、tmpfs は違いを生みません。 /P>
実行するディスク I/O がない場合、tmpfs は何の違いもありません。
大量のディスク I/O があり、ストレージが追いつくのを待ってプロセスがブロックされている場合、tmpfs で実行すると大きな違いが生じます。ディスクが遅いほど違いが大きくなり、CPU がボトルネックになるところまでいきます。
<ブロック引用>
(4) 実行可能ファイルは Docker コンテナー内から実行され、実行可能ファイルと関連するすべてのファイルは、コンテナー内から作成された tmpfs フォルダー内の「内部」ドライブ (コンテナーが停止した後は保持されません) にあります。 /P>
(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 にはまだ余裕があるかもしれませんが、何らかの理由で、も それ以外の場合はメモリ ページを書き込む必要があり、何も残っていません。
そのため、カーネルは何かを行う必要があります システムを稼働し続けるために。 どういうわけか 問題を軽減するためにリソースを再配置します (おそらく docker プロセスとコンテナー全体を交換しますか?!)。カーネルは懸命に努力しますが、魔法を実行できるわけではなく、何かをする必要があります であり、その選択肢は限られています。さらに言えば、必要に応じて自由に使用できる膨大な数のページを意図的に削除したためです (今すぐ処理する必要があるリクエストを含む)。