問題タブ [tmpfs]

tmpfs を 50% に設定し、後で RAM を追加または削除した場合、tmpfs はそのパーティション サイズを自動的に調整しますか?

また、複数の tmpfs がそれぞれ 50% に設定されているとどうなりますか。複数の tmpfs が同じ 50% をめぐって互いに競合しますか? これはOSによってどのように管理されていますか？

ISO イメージ (ストック Ubuntu 13.10 DVD ISO イメージ) が OS の前にメモリにロードされており、このイメージから Linux のインストール プロセスを開始しようとしています。GRUB はイメージを CD として認識でき、インストールを開始できます (UEFI プラットフォームで実験しており、サポートされているファイル システムでイメージを有効なブロック デバイスとして認識できるように、GRUB の UEFI バージョンを使用しています)。

私の問題は、カーネルがインストール メディアを見つけられない (これは予想されることです) ため、早い段階でパニックが発生することです。カーネルがイメージを見つけられるように単純なブロックデバイスドライバーを作成できることはわかっていますが、移植性のために、特定の開始アドレスに tmpfs/ramfs をマウントする方法はありますか? または、特定のアドレスにファイル システムがあることをカーネルに伝える方法はありますか?

ありがとう

共有メモリ/ 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 キャッシュにコピーされます。

私が変更できないプログラムは、その出力を引数として提供されたファイルに書き込みます。不要なディスク IO を実行する必要がないように、出力を RAM に送りたいと考えています。tmpfs を使用してプログラムを「トリック」してそれに書き込むことができると思いましたが、すべての Linux ディストリビューションが /tmp に tmpfs を使用するわけではなく、/run (Ubuntu) の下に tmpfs をマウントするものもあれば、/dev/shm (RedHat) の下にマウントするものもあります。私は自分のプログラムを可能な限り移植可能にしたいと考えており、できればユーザーのシステムに tmpfs ファイル システムを作成したくありません。明らかに、私は df | を実行できます。tmpfs を grep し、返されたマウントを使用しますが、もう少しエレガントなものを望んでいました。疑似端末または /proc のどこかに書き込むことは可能ですか?

ユーザーが入力した正規表現を受け入れ、それを使用して大きなテキスト ファイル (940 万行、約 160 MB) を検索する PHP Web スクリプトがあります。スクリプトの最初の繰り返しでは、ファイルを通常のファイル システムに置き、検索が必要な場合は fopen / fgets を使用してアクセスし、1 行ずつ検索しました。正規表現の複雑さにもよりますが、スクリプトはファイル全体を 30 ～ 45 秒で処理しました。

速度を上げるために、1 GB の tmpfs パーティションをマウントし、大きなテキスト ファイルをそこに移動しました。次に、PHP スクリプトのパスを変更し、すぐに改善されることを望んでいました。ただし、スクリプトがファイルを解析する速度は変わっておらず、複数回実行すると、通常のファイル システムからファイルを読み取る場合よりも遅くなることがありました。

さらに、PHP でファイル全体を RAM にロードしようとしましたが、最初に配列にプルしたところ、検索時間が 40% ほど改善されました。残念ながら、ファイルをアレイに最初にロードする時間が非常に長いため、これは私にとって受け入れられる方法ではありません。

これはすべて、12 GB の RAM を搭載し、Debian 7 を実行し、nginx / php5-fpm を使用する仮想サーバーで発生しています。

tmpfs で何が起こっていますか? 足りないものはありますか？必要な追加情報を提供します。