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.04MB /秒
ボリュームグループ/ 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マニュアルページのセクションを参照してください。
-tベンチマークと比較の目的でデバイス読み取りのタイミングを実行します。意味のある結果を得るには、少なくとも数メガバイトの空きメモリがある、そうでない場合は 非アクティブなシステム（他のアクティブなプロセスはない）で、この操作を2〜3回繰り返す必要があります。これは、事前にデータをキャッシュせずに、バッファ キャッシュを介してディスクに読み取る速度を表示します。この測定は、 Linuxでドライブがファイルシステムのオーバーヘッドなしでシーケンシャルデータ読み取りを維持できる速度を示しています。正確な測定を確実にするために、BLKFLSBUF ioctlを使用して-tの処理中にバッファーキャッシュがフラッシュされます。 -Tフラグも指定されている場合は、-Tの結果に基づく補正係数が、-t 操作で報告された結果に組み込まれます。
LVMのデフォルトの先読み設定はreally pessimisticです。 blockdev --setra 8192 /dev/vg1/vol1を試して、LVMのパフォーマンスを最大に引き上げるものを確認してください。 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によって提案された change を作成し、このような結果を見ました。
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）。