16

4TB HDD ext4 ファイルシステム上のファイルに格納された 1e12 32 ビット整数 (4 TB) の配列であるデータセットがあるとします。

データがランダムである可能性が最も高い (または少なくともランダムに見える) ことを考慮してください。

// pseudo-code
for (long long i = 0; i < (1LL << 40); i++)
   SetFileIntAt(i) = GetRandInt();

さらに、個々の int 要素を予測できない順序で読み取り、アルゴリズムが無期限に実行されることを考慮してください (進行中です)。

// pseudo-code
while (true)
   UseInt(GetFileInt(GetRand(1<<40)));

Linux x86_64、gcc を使用しています。システムには 4 GB の RAM があると想定できます (つまり、データセットの 1000 分の 1 未満)。

アクセスを設計するには、次の 2 つの方法があります。

(A) ファイルを 4TB のメモリ ブロックに mmap し、int 配列としてアクセスします。

(B) ファイルを open(2) し、seek(2) と read(2) を使用して int を読み取ります。

A と B のうち、どちらが優れたパフォーマンスを発揮するでしょうか? また、その理由は?

AまたはBよりも優れたパフォーマンスを発揮する別の設計はありますか?

4

4 に答える 4

3

一方で、メモリ スワップを多用すると、マイナーページフォールトが発生し、アプリケーションに対して透過的になります。もう一方には、既知のオーバーヘッドを伴う多数のシステム コールがあります。メモリ マップト ファイルに関するウィキペディアのページは、私には非常に明確なようです。長所と短所を包括的に参照しています。

少なくともアプリカティブを複雑にしないためには、64 ビット アーキテクチャ + メモリ マップド ファイル アプローチの大きなファイル呼び出しが必要だと思います。複雑さはパフォーマンスの低下につながることが多いと言われています。ただしmmap()、シーケンシャル アクセスでは通常のことであり、ここでの目的ではありません。

これは純粋なランダム アクセスであるため、2 つのアクセスが同じ RAM ロード ページにある可能性はほとんどありません。4バイトのデータのためだけに、4kbのページ全体がHDDからRAMにスワップされます...これは無駄なバスのロードであり、パフォーマンスの低下につながる可能性があります。

この助けを願っています。

于 2012-06-14T11:54:56.880 に答える
1

おそらく 4TB の線形データセットの場合、ファイル システムは必要ありません。raw デバイス アクセスは、パフォーマンス上の利点をもたらす可能性があると思います。

また、キャッシュをより効率的に使用できるように、おそらくクエリまたはデータ構造を最適化する方法がありますか?

于 2012-06-16T20:03:54.463 に答える
1

シークのパフォーマンスは、ファイル システムの実装に大きく依存します。Ext4 はエクステント ツリーを使用するため、適切な選択です。また、ファイルに線形連続割り当てがある場合、エクステント ツリーは単一のエントリで構成されるため、シークが非常に効率的になります。

于 2016-03-09T08:57:58.750 に答える
1

アクセスが本当にランダムな場合、パフォーマンスは同様になるはずです。OS は、データ ページがファイルからマップされるか、ファイル データが RAM に関連付けられずに単にキャッシュされるかにかかわらず、同様のキャッシュ戦略を使用します。

キャッシュが無効であると仮定します。

  • を使用fadviseして、事前にアクセス パターンを宣言し、先読みを無効にすることができます。
  • アドレス空間レイアウトのランダム化により、仮想アドレス空間に 4 TB の連続ブロックが存在しない場合があります。
  • データ セットが拡張された場合、アドレス空間の問題はより差し迫ったものになる可能性があります。

したがって、明示的な読み取りを使用します。

于 2012-06-14T12:51:19.030 に答える