Linux mdとLVMのパフォーマンス

NASを調整し、openfilerを実行していて、RAID 5の4つのWD RE3ドライブからの読み取りパフォーマンスが比較的低いのはなぜかと思います。

編集：私はバッファリングされたディスクの読み取り速度がキャッシュされた速度ではないことに注意してください

編集：2つの出力セットがあることを明確にするために書式を変更しました。

メタデバイスでhdparmを実行すると、期待どおりのパフォーマンスレベルが得られます。ボリュームに落とすと、速度は3分の1になります。

なぜ誰か何か考えはありますか？LVMはそんなに悪いのですか？

ディーン

メタデバイス/ dev / md0の結果

[root @ nas2 etc]＃hdparm -tT / dev / md0
/ dev / md0：
 キャッシュされた読み取りのタイミング：2.00秒で4636 MB = 2318.96 MB /秒
 バッファリングされたディスク読み取りのタイミング：3.01秒で524 MB = 174.04 MB /秒

ボリュームグループ/ dev / mapper / vg1-vol1の結果

[root @ nas2 etc]＃hdparm -tT / dev / mapper / vg1-vol1
/ dev / mapper / vg1-vol1：
 キャッシュされた読み取りのタイミング：2.00秒で4640 MB = 2320.28 MB /秒
 タイミングバッファディスクの読み取り：3.01秒で200 MB = 66.43 MB /秒

編集：これは、これが解決しようとしている問題であるシーケンシャルリードパフォーマンスの完全に有効なテストであることを示唆するhdparm manページのセクションを参照してください。

-tベンチマークと比較のために、デバイスの読み取りタイミングを実行します。意味のある結果を得るには、この操作を2〜3回繰り返します。
              非アクティブなシステム（他のアクティブなプロセスなし）、少なくとも数メガバイトの空きメモリ。バッファを介して読み取る速度を表示します
              事前にデータをキャッシュせずにディスクにキャッシュします。この測定値は、ドライブが連続データ読み取りをどれだけ速く維持できるかを示しています
              Linux、ファイルシステムのオーバーヘッドなし。正確な測定を確実にするために、BLKFLSBUFを使用して-tの処理中にバッファーキャッシュがフラッシュされます。
              ioctl。-Tフラグも指定されている場合、-Tの結果に基づく補正係数が-tについて報告された結果に組み込まれます。
              操作。

LVMのデフォルトの先読み設定は本当に悲観的です。blockdev --setra 8192 /dev/vg1/vol1LVMのパフォーマンスを最大に引き上げるものを試してみてください。LVMを使用すると、常にパフォーマンスが低下します。適切に構成されたシステムで、基本的なブロックデバイスパフォーマンスの約10％で測定します。

良い説明はありませんが、結果は確認できました。

RAIDのテスト（raid5、4x1.5TBドライブ）

root@enterprise:# hdparm -tT /dev/md2
/dev/md2:
 Timing cached reads:   2130 MB in  2.00 seconds = 1065.81 MB/sec
 Timing buffered disk reads:  358 MB in  3.00 seconds = 119.15 MB/sec
root@enterprise:# hdparm -tT /dev/md2
/dev/md2:
 Timing cached reads:   2168 MB in  2.00 seconds = 1084.54 MB/sec
 Timing buffered disk reads:  358 MB in  3.01 seconds = 119.10 MB/sec

md2を物理デバイスとして使用するボリュームのテスト。

root@enterprise:# hdparm -tT /dev/mapper/vg2-data
/dev/mapper/vg2-data:
 Timing cached reads:   2078 MB in  2.00 seconds = 1039.29 MB/sec
 Timing buffered disk reads:  176 MB in  3.03 seconds =  58.04 MB/sec
root@enterprise:# hdparm -tT /dev/mapper/vg2-data
/dev/mapper/vg2-data:
 Timing cached reads:   2056 MB in  2.00 seconds = 1028.06 MB/sec
 Timing buffered disk reads:  154 MB in  3.03 seconds =  50.81 MB/sec

私はwomble が提案した変更を行い、このような結果を見ました。

root@enterprise:# blockdev --setra 8192 /dev/mapper/vg2-data

root@enterprise:# hdparm -tT /dev/mapper/vg2-data
/dev/mapper/vg2-data:
 Timing cached reads:   2106 MB in  2.00 seconds = 1053.82 MB/sec
 Timing buffered disk reads:  298 MB in  3.00 seconds =  99.26 MB/sec
root@enterprise:# hdparm -tT /dev/mapper/vg2-data
/dev/mapper/vg2-data:
 Timing cached reads:   2044 MB in  2.00 seconds = 1022.25 MB/sec
 Timing buffered disk reads:  280 MB in  3.03 seconds =  92.45 MB/sec

リンゴとリンゴを比較してください。

hdparm -t ディスク全体を提供している場合は、デバイスの最初から読み取ります。これは、ディスクの最も速い部分でもあります（回転しているプラ​​ッターです）。

ディスクの最初からLVと比較してください。

マッピングを表示するには、を使用しますpvdisplay -m。

（もちろん、数の違いは無視できるかもしれませんが、少なくともそれについて考えてください:)

hdparm -Tによって作成されたワークロードは、単一の大きなファイルからの読み取りをストリーミングすることを除いて、ほとんどすべてのユースケースを代表するものではありません。また、パフォーマンスが問題になる場合は、raid5を使用しないでください。

hdparmがblktrace（I / Oにある場合）またはoprofile（CPUにある場合）で時間を費やしている場所を把握できます。LVM設定を知っていることも役立ちます（pvdisplay、vgdisplay、lvdisplay）。