3

誰かがこれをベンチマークしましたか？書き込み呼び出しのレイテンシーを最小限に抑えて、できるだけ速くディスクに書き込みたいと考えています。Java側でコンテンツをバッファリングし、バッファがいっぱいになったらfileChannelにフラッシュするよりも、（buffer.put（）を介して）メモリマップバッファに書き込む方が速いのではないかと思います。そうすれば、バッファがいっぱいになったら、システム コール (FileChannel.write) を実行するだけです。MappedByteBuffer にバイトを書き込むとどうなるか、つまり、システム コールが実行されたかどうかはわかりません。

バッファリングされたアプローチでは、16、32、または 64k のチャンクでディスクに書き込むことができ、これが最適であると考えています。バッファリングの欠点は、アプリケーションがクラッシュした場合にコンテンツをフラッシュするためのシャットダウン フックが必要なことです。また、ファイル チャネルに直接書き込むのではなく、バッファーにコピーする追加のレイヤー。また、ファイルを末尾にすると、コンテンツがバッファリングされるため、必要なものが表示されない場合があります。また、メモリ マップ ファイルを末尾にするとどうなるかわかりません。

経験豊富な魂がここで助けてくれますか?

4

1 に答える 1

4

レイテンシーを最小限に抑えようとしている場合、システムコールを行う必要がないため、MemoryMappedFilesへの書き込みが高速であることがわかりました。これは、データをディスクに強制する必要がなく、OSがベストエフォートベースでこれを実行できることを前提としています。

MemoryMappedFileへの書き込みの一般的な待機時間は、メモリへの書き込みと同じであるため、速くなるとは思いません。ファイルが大きくなるにつれて、追加のメモリマップ領域を実行する必要があります。これには50〜100マイクロ秒かかる場合があります。これは重要ですが、問題にならないほどまれなはずです。

システムコールを介したIOへの書き込みには、5〜10マイクロ秒のオーダーがかかります。これは、より多くのアプリケーションには十分な速度ですが、重要な場合は比較的遅くなります。

低レイテンシで書き込まれるデータを確認する必要がある場合は、書き込まれた時点から通常100nsのレイテンシでデータの読み取りをサポートするライブラリJavaChronicleを確認することをお勧めします。

注：メモリマップトファイルは個々の書き込みの待ち時間を短縮できますが、ディスクサブシステムの書き込みスループットは向上しません。これは、低速のディスクサブシステムを使用している場合、メモリがすぐに使い果たされることを意味します（GBが多い場合でも）。これは、どのアプローチを採用するかに関係なく、パフォーマンスのボトルネックになります。

たとえば、SATAまたはファイバーを使用している場合、500 MB / sの制限があり、これを簡単に超えることができます。この場合、メモリ制限に達すると、選択した内容に関係なく速度が低下します。

于 2012-10-21T17:20:56.713 に答える