1

私は数億のファイル(数ペタバイト)のファイルシステムを持っており、statが返すほとんどすべてのものを取得して、ある種のデータベースに保存したいと考えています。現在、中央キューからディレクトリ名が供給されるMPIプログラムと、統計呼び出しでNFSを非難するワーカーノード(これはあまり努力せずに処理できます)があります。次に、ワーカーノードはpostgresを押して結果を保存します。

これは機能しますが、非常に遅いです。最新の30ノードクラスターでは、1回の実行に24時間以上かかります。

一元化されたキューを使用する代わりに、ディレクトリ構造を分割するためのアイデアはありますか(このための正確なアルゴリズムはNP困難であるという印象を受けています)。また、postgresをいくつかのルーターを使用したMongoDBの自動シャーディングのようなものに置き換えることを検討しています(postgresは現在大きなボトルネックになっているため)。

私は、この設定をどのように改善できるかについての一般的なアイデアを探しています。

残念ながら、2.6カーネル監査サブシステムのようなものを使用することは、このファイルシステムにヒットするすべてのマシンでそれを実行することは(政治的な方法で)非常に難しいため、おそらく問題外です。

重要な場合は、このファイルシステムを使用するすべてのマシン(数千台)がLinux2.6.xを実行しています。

これの実際の主な目的は、特定の日付より古いファイルを見つけて、それらを削除できるようにすることです。また、ファイルシステムがどのように使用されているかに関する一般的なデータも収集したいと思います。

4

2 に答える 2

1

私のコメントを拡張します。

ファイルを中央の場所に置くことは、最大のボトルネックの 1 つです。他の方法でファイルシステムのアクセス時間を最適化できない場合、おそらく最善の方法は、1 つ (または 2 つ) のワーカーにstat呼び出しを実行させることです。ワーカーはすべて同じファイルシステムにアクセスしているため、複数のワーカーを追加してもパフォーマンスは向上しません。

このため、(NFS 経由でアクセスするのではなく) ファイルシステムが配置されているノードにワーカーを配置すると、パフォーマンスが大幅に向上するはずです。

一方、データベースの書き込みは、db エンジンを変更することで最適化できます。コメントで予想されているように、Redisキー値モデルはそのようなタスクにより適しています (はい、かなり高速です): そのハッシュ タイプstatを使用して、フル パス名をキーとして呼び出しの結果を格納できます。

さらに、近い将来、redis はクラスタリングもサポートする予定です。

于 2011-08-04T22:10:31.440 に答える
0

最終的には、(redis を使用して) 独自のソリューションを作成することになりました。実行時間を約 24 時間から約 2.5 時間に短縮しました。

于 2011-10-11T20:20:43.807 に答える