共有メモリ/ tmpfs / mmap /ブロック読み取りの一般的な比較を求めるこの質問のいくつかの一般的なバージョンに出くわしましたが、この質問のアプリケーション固有のバージョンを試して、より効率的なアプローチを見つけたいと思いましたレイテンシの条件。
メモリへの直接バイト配列オプションを提供するのではなく、名前付きファイルに書き込むオプションのみを提供する画像処理ライブラリのバインディングがあります。このライブラリを、さまざまな形式とサイズのソース画像を読み取り、サイズ/色の変換を適用し、この画像のサムネイル バージョンをメモリの LRU キャッシュにキャッシュするサーバーの一部として使用しています。次に、サーバーはこれらのサムネイルを LRU から http 経由で提供します。サーバーには、限られた数のイメージ ワーカーがあります (2 ～ 4 など)。ソース イメージの平均サイズは 100KB ～ 20MB です。出力画像のサイズは、平均 20KB ～ 1MB の範囲です。
私が使用していた以前の画像処理ライブラリには、出力画像をバイト配列に書き込む機能がありましたが、現在、この別のライブラリに切り替えようとしています。そのため、この出力制限を回避するためのオプションを評価しています。
私はオプションとしてmmapと を調査しtmpfsており、アイデアの組み合わせがいくつかありますが、私のアクセスパターンに基づいて、オーバーヘッドまたは複雑さに関する情報に基づいた応答を聞きたいと思っています.
私の懸念/dev/shmは、自分のアプリ用に自分で構成/マウントする必要がなく、固定サイズである可能性があるため、移植性に関するものでした (ただし、存在する可能性が高く、十分に大きい)。/tmpまた、たとえば、通常のブロックでバックアップされた事前割り当てファイルが mmap され、イメージ ライブラリがそれに書き込み、そこから読み返すときに、フードの下で何が起こるかについても明確ではありません。物事の読み取りサイズに利点はありますか?
概要
{file,memory} でバックアップされたイメージ バッファを使用するための次の潜在的なアプローチは、mmap の適切な使用法ですか?
- がマウントされている場合
/dev/shm、イメージ ワーカーごとにメモリ バックアップ ファイルを事前に割り当てます。 /dev/shmがマウントされていない場合は、/tmpイメージ ワーカーごとに通常のファイルを事前に割り当てます。- サーバープロセスの長さの間、ワーカーごとに mmap を開いたままにします。出力画像データは、画像ライブラリからファイル パスに書き込まれ、次に mmap バイト配列を介してアクセスされ、LRU キャッシュにコピーされます。