Linuxにswapfileにファイルをキャッシュするように指示します
背景：Linux VFSキャッシュは、ディスクから読み取られたすべてのファイルをメモリにキャッシュします。これは、RAMがいっぱいになるまで続きます。いっぱいになると、最も古いファイルがキャッシュから追い出されます。
ネットワーク接続ストレージでXenServerを実行しています。私のサーバーは、ネットワーク接続ストレージにルートファイルシステムを持っています。また、各XenServerホストにローカルディスクがあります。私のサーバーは、このローカルストレージにスワップパーティションを持っています。私の特定のケースでは、ネットワーク接続ストレージがロードされ、ディスクIOがかなり遅くなる可能性があります。ローカルディスクがRAIDを使用していないか、保護されていないため、このような設定があります。失うのはスワップパーティションだけなので、私のシステムはローカルディスクの障害に耐えることができます。
Linuxに（RAMに加えて）スワップパーティションをキャッシュファイルで埋めるように指示する方法を誰かが知っているかどうか疑問に思っていますか？すべてのローカルディスクを使用する物理サーバーでは、これは速度の利点にはなりませんが、私のサーバーにとっては非常に理にかなっています。
あなたがやろうとしていることの問題は、VFSキャッシュが完全にカーネル内で制御されており、問題のあるスペースが非常にニッチなものであるということです-一般に、キャッシュをスワップに入れると、キャッシュの目的が完全に無効になります（私は同意しますが）あなたのユースケースは有効なものです）。私の言いたいことは、あなたがやりたいことが現在カーネルでサポートされている可能性は非常に低いということです（そして、あなたがやりたいことが可能であるということについて、どんな種類のゴロゴロも聞いたことがありません）。
Qemuなどのより「疑似」仮想化テクノロジーを実行している場合は、VMによって使用されるメモリを「オーバーコミット」することができます。このようにして、VMによって使用されるメモリは、「通常の」プロセスメモリとしてホストに表示されやすくなり、ホストのスワップスペースを使用して、そうでないときにページアウトすることができます。これは、VM内のプロセスが実際にそのすべてのメモリを必要とする場合、またはVM内のキャッシュの負荷が強い場合に、マシンをスワップして停止するリスクを伴いますが、注意深く調整することで機能する可能性があります。
VFSキャッシングはすべてカーネルレベルであり、（ここでも）ユーザースペースでそれを管理するためのユースケースは非常にニッチであるため、ユーザースペースでこの種のものを管理しようとする試みは機能しない可能性があります。キャッシュしようとしているのがアプリケーションデータの場合は、データにユーザースペースキャッシュを提供できます（ファイルシステムでFuseを使用できる方法で必要な場合は、アプリケーション固有のデータストアの方が適しています）が、それは両方とも多くのことです。作業量（キャッシュを正しく行うのは簡単ではありません）であり、キャッシュする必要があるルートファイルシステムの場合は機能しません。
これがしばらくの間価値があると判断した場合は、このユースケースをサポートするために、独自のカーネルレベルのコードの記述とデバッグに多くの時間を費やすことになると思います。問題を「スワップにキャッシュを保存する」（多くの人の防御をすぐに強化する）に一般化するのではなく、VFSではなくスワップスペースを使用するある種の「SANデバイスキャッシング」メカニズムがより簡単かもしれません。 -メモリキャッシュ。 「簡単」ではなく「簡単」と言っていることに注意してください。それでも多くの作業が必要になります。
カーネルの変更を検討する前に、NAS/SANのパフォーマンスを改善するために多くの努力（およびお金）を費やすことをいとわないでしょう-正直なところ、キャッシュよりもコストパフォーマンスが高いからです。キャッシングを使用すると、初期アクセスは常に基盤となるアクセスメカニズムと同じくらい遅くなります。これを高速化できれば、高速で低速の初期アクセスを行うよりも、知覚されるパフォーマンスが向上する可能性があります（まれ）繰り返しアクセス。また、すべてのVMにバケット全体の負荷を増やすだけのコストも考慮してくださいRAM-たくさんのRAMを1〜2か月のコストで購入できますカーネルハッキング。