問題タブ [mmap]

サイズが100GB以上になる可能性のあるファイルを処理するプログラムに取り組んでいます。ファイルには、可変長レコードのセットが含まれています。私は最初の実装を立ち上げて実行しており、現在、特に入力ファイルが何度もスキャンされるため、I/Oをより効率的に実行することでパフォーマンスの向上を目指しています。

mmap()C ++のライブラリを介してブロックを使用するか読み取るかについての経験則はありfstreamますか？私がやりたいのは、ディスクからバッファーに大きなブロックを読み取り、バッファーから完全なレコードを処理してから、さらに読み取ることです。

'dブロックはページサイズの境界上にある必要があり（私の理解）、レコードはページ境界を越えて存在する可能性があるため、mmap()コードは非常に乱雑になる可能性があります。mmapsを使用fstreamすると、ページサイズの境界にあるブロックの読み取りに制限されないため、レコードの先頭を探して再度読み取りを開始できます。

最初に完全な実装を実際に作成せずに、これら2つのオプションのどちらかを決定するにはどうすればよいですか？経験則（たとえば、mmap()2倍速い）または簡単なテストはありますか？

POSIX 環境では、ファイルにアクセスする方法が少なくとも 2 つあります。標準的なシステム コールopen()、read()、write()、およびその仲間がありますがmmap()、ファイルを仮想メモリにマップするために使用するオプションもあります。

どちらか一方を使用するのが望ましいのはいつですか? 2 つのインターフェイスを含める価値がある個々の利点は何ですか?

私は、リクエストに応じてアーティファクトを構築するために何千もの小さなファイルを使用するJavaWebアプリケーションに取り組んでいます。これらのファイルをディスク全体で実行して常に見つけるのではなく、これらのファイルをメモリにマップできれば、システムのパフォーマンスが向上すると思います。

Linuxでmmapについて聞いたことがありますが、その概念の基本的な理解は、ファイルがディスクから読み取られると、ファイルの内容がメモリのどこかにキャッシュされ、その後のアクセスが速くなるということです。私が考えていることはその考えに似ていますが、私のWebアプリが最小限の要求時間応答のために初期化しているので、mmap可能なファイルのセット全体をメモリに読み込みたいという点が異なります。

ここでの私の思考訓練の1つの側面は、ファイルがすべてタール化され、何らかの方法で仮想ファイルシステムとしてJVMにマウントされた場合、ファイルをjvmメモリにすばやく取り込むことができるということです。現状では、現在の実装がソースファイルのセットを調べて、ディスク上にあるものをすべて把握するのに数分かかる場合があります。これは、基本的に300,000を超えるファイルのファイル統計を実行しているためです。

tarファイルから情報を読み取ることができるapacheVFSプロジェクトを見つけましたが、「また、tar全体をメモリに読み込んで保持する」などの指定ができるかどうかは、ドキュメントからはわかりません。

ここでは、マルチスレッド環境について話しています。アーティファクトは、通常、300,000以上のソースファイルの完全なセットから約100の異なるファイルをつなぎ合わせて、1つの応答を作成します。したがって、仮想ファイルシステムソリューションが何であれ、スレッドセーフでパフォーマンスが高い必要があります。ここでは、ファイルの読み取りについてのみ説明しており、書き込みについては説明していません。

また、32ギガのRAMを搭載した64ビットOSを実行しており、300,000ファイルは約1.5〜2.5ギガのスペースを占有します。確かに、2.5ギガバイトのファイルを300Kの小さな数キロバイトサイズのファイルよりもはるかに高速にメモリに読み込むことができます。

入力ありがとうございます！

• ジェイソン

私は現在、PHP/FastCGI のいくつかのコピーを実行しており、APC が有効になっています (問題がある場合は、Apache+mod_fastcgi の下で)。プロセス間でキャッシュを共有できますか? すでに共有されているかどうかを確認するにはどうすればよいですか? (iniの設定が関係していると思いますが、apc.mmap_file_mask使い方がわかりません。)

(現時点で共有されていないと私が考える理由の 1 つはapc.mmap_file_mask、apc.php Web インターフェイスによって報告されたように、リロード時に約 3 つの異なる値の間で切り替わるためです。)

保護フラグはプロセス間の共有に影響しますか? PROT_READ|PROT_WRITE で保護された mmaped メモリ領域がある場合、書き込みを行っていない限り、完全に共有されますか?

対:

必要に応じて小さな部分を保護するよりも簡単なので、マップした後にメモリ領域の小さな部分に小さな変更を加えてから、すべてを再保護したいと思います。

問題は、プロセスごとにコピーされたファイル全体を強制するのか、それともプロセスごとに変更した部分だけを強制するのかということです。

fork + exec を使用して生成されたプロセスにポインターを渡したい (mmap を使用してデータを含むファイルをメモリに配置している) のですが、exec() で生成されたプロセスにポインターを渡す方法に行き詰まっていますか?

更新1:

ご意見をお寄せいただきありがとうございます。共有メモリを使用して、mmap と MAP_INHERIT フラグを使用して作成しています。

mmap() 関数で作成されたマップされた各ファイルと共有メモリー領域は、MAP_INHERIT オプションでマップされた領域を除き、いずれかの exec 関数の呼び出しが成功するとマップ解除されます。MAP_INHERIT オプションでマップされた領域は、新しいプロセス イメージにマップされたままになります。

ソース: http://www.uwm.edu/cgi-bin/IMT/wwwman?topic=exec(2)&msection=

更新 2:

これは宿題ですが、ポインターについて考えるのをやめて、IPC 自体について考えなければならないと思います。子プロセスで同じファイルを mmap しようとすると思います。

短いコードの例は大歓迎です。

よろしくお願いします。

Linuxのダイレクトメモリアクセスに投稿したドライバーを使用して、物理RAMをユーザースペースアドレスにmmapしています。ただし、GDBを使用してアドレスを確認することはできません。つまり、x 0x12345678（0x12345678はmmapの戻り値）は、「アドレス0x12345678のメモリにアクセスできません」というエラーで失敗します。

このメモリを表示できることをGDBに伝える方法はありますか？あるいは、このメモリにアクセスできるようにするために、mmap（そこでのfoo_mmapの呼び出しまたは実装のいずれか）で実行できる別のことはありますか？

/ dev / memについて質問しているのではなく（最初のスニペットのように）、ioremap（）、virt_to_phys（）、およびremap_pfn_range（）を介して取得したメモリへのmmapについて質問していることに注意してください。

メモリ マップト ファイルのサイズを制限するものは何ですか? 割り当てられていないアドレス空間の最大連続チャンクよりも大きくすることはできず、十分な空きディスク容量が必要であることはわかっています。しかし、他の制限はありますか？

同じファイルのメモリマッピングを使用して、2つの異なるプロセスが通信できるようにしようとしています。しかし、私はこれに関していくつかの問題を抱えています。これは、open（）呼び出しを使用して、ファイル記述子をmmapに渡す方法に関係していると感じています。

これが私のコードです、何か問題がありますか？

オブジェクト1のコード：

オブジェクト1は一度だけ作成され、既存のデータをリセットしたいので、「w」ファイルモードを使用します。

オブジェクト2のコード：