web-dev-qa-db-ja.com

RAID5での1,000〜2,000万ファイルのストレージの最適化（現在LVM + XFSを使用）

ここでいくつかの質問を参照しましたが、状況はそれぞれ異なり、まったく異なる解決策が必要になる可能性があると思います。

私が今持っているもの：

  • 4x4TBエンタープライズHDD上のLinuxソフトウェアRAID5
  • いくつかのボリュームを備えたLVM
  • 最も重要なストレージボリューム、10TB XFS
  • DebianWheezyのデフォルトパラメータを使用したすべてのセットアップ
  • ボリュームはオプション「noatime、nodiratime、allocsize = 2m」でマウントされます
  • 約8GB RAM無料でキャッシュに使用されていると思いますが、HTを搭載したクアッドコアIntelCPUはあまり使用されていません

このボリュームには、ほとんどの場合、100Kから2Mの間に約1,000万個のファイル（将来的には最大2,000万個）が格納されます。これは、ファイルサイズの範囲（K単位）と範囲内の数値のより正確な分布です。

       4    6162
       8      32
      32      55
      64   11577
     128    7700
     256    7610
     512     555
    1024    5876
    2048    1841
    4096   12251
    8192    4981
   16384    8255
   32768   20068
   65536   35464
  131072  591115
  262144 3411530
  524288 4818746
 1048576  413779
 2097152   20333
 4194304      72
 8388608      43
16777216      21

ファイルは主に、次のようにボリュームのレベル7に保存されます。

/volume/data/customer/year/month/day/variant/file

通常、これらのフォルダ内には最大1〜2Kのファイルがあり、場合によってはそれより少なく、場合によっては最大5〜10K（まれなケース）です。

I/Oはそれほど重くはありませんが、もう少し押すとハングします。例えば：

  • ほとんどのI/Oを実行するアプリケーションは、読み取りと書き込みの両方にNGINXです。
  • 合計1〜2MB /秒のランダムな読み取りがいくつかあります
  • データが1〜2MB /秒の速度で継続的に書き込まれるフォルダがいくつかあり、1時間より古いすべてのファイルを定期的にフォルダから削除する必要があります

次のcronを1時間に1回実行すると、サーバー全体が数秒間ハングし、I/Oタイムアウトが生成されるため、サービス（新しいデータの書き込み）が中断される場合があります。

find /volume/data/customer/ -type f -iname "*.ext" -mmin +60 -delete
find /volume/data/customer -type d -empty -delete

また、上記の範囲でファイルを書き込むと、書き込み速度が遅くなります（数MB /秒）。より大きなファイルを書き込む場合、書き込みキャッシュがいっぱいになるまで（明らかに）問題はなく、その後速度が低下し、サーバーが波のようにハングし始めます。

現在、デフォルトでは最適ではなく、多くの点で改善される可能性があるため、ストレージのパフォーマンスを最適化するためのソリューションを探しています。私にとってはそれほど有用ではありませんが、LVMを削除してもサーバー全体を再インストールしないため、大きな利益が得られない場合はLVMを削除しません。

XFS vs. ReiserFS vs. Ext4についてたくさん読んでいますが、私はかなり戸惑っています。 RAID1 2TBボリュームがはるかに小さいが、セットアップがまったく同じで、ワークロードが大幅に重い他のサーバーは、まったく問題なく動作します。

何か案は？

どのようにデバッグ/実験する必要がありますか？

ありがとう。

filesystemslvmraid5performance-tuningxfs
3
bigfailure

まず、シナリオの場合、XFSはこの種の正しい選択です。XFSを使用すると、iノードから抜け出すことはほとんど不可能です。

削除のパフォーマンスを向上させるには、次のことを試してください。

  • （デフォルトの）deadlineではなく、cfq I/Oスケジューラを使用します
  • マウントオプションとしてlogbsize=256k,allocsize=64kを使用します（nodiratime,noatimeに加えて）

他のシステムアクティビティへの削除の影響を減らすには、ionice -c 2 -n 7を使用してfindスクリプトを実行してみてください

結果を報告してください！

1
shodanshok

締め切りはおそらく良い考えであるというShodanshokに同意します。ここでXFSを使用する必要があるとは確信していません。

/ volume/data/customer/-type f -iname "* .ext" -mmin + 60-deleteを検索します

XFSは、ファイルの削除に非常に悪かったものでした。この領域のバグのほとんどは解決されたと言われていますが、これを確認するためのハードベンチマークは行われていません。

書き込みキャッシュが（明らかに）いっぱいになり、速度が低下してサーバーが波にぶら下がるまでは問題ありません。

ぶら下がっていますか？ダーティページの比率を調整する必要があるようです（バックグラウンドraioを減らし、ブロック率を上げる）。また、dirty_expire_centisecsを変更し（上下-何が速くなるかを確認してください）、全体的な負荷とCPU使用率が許容できる場合はdirty_writeback_centisecsを減らす必要があります。 。

'find'ステートメントがデータの大部分を処理している場合は、vfs_cache_pressureを微調整することをお勧めします。繰り返しになりますが、正しい値を見つける唯一の方法は試行錯誤ですが、ファンアウトが非常に高く、おそらくデータファイルの読み取りがそれほど多くない場合は、値を減らすとキャッシュの効率が向上します。

LVMスナップショットはIOスループットを停止することに注意してください。

----上記のものは、選択したファイルシステムに関係なく適用されます----

ファイルシステムを選択する際の最も重要な考慮事項は、ファイルシステムの堅牢性です。これらがすべて一時ファイルであり、停止した場合でもすべてを失うことを気にしない場合/停止後の高速リカバリ時間を必要としない場合は、ジャーナリングファイルシステムを使用しないでください。しかし、あなたは私たちにデータについてあまり話していない。

ファンアウトが大きいことに注意してください.... ext3/4のdir_index機能が明示的に追加され、ディレクトリに多数のファイルが含まれている場合やファイルの回転率が高い場合に、より高速で効率的な解決が可能になりました。このシナリオでXFSがどれほど効果的かはわかりません。

ReiserFSはもうあまりサポートされていません。

あなたが見たいと思うかもしれない他のいくつかのものがあります（UPS、bcache、専用ジャーナルデバイスを含む）が、それなら私は 主題に関する本を差し込む の言い訳はありません。

1
symcbean