web-dev-qa-db-ja.com

Samsung 840 ProSSDで構築されたソフトウェアraid1アレイに関するさまざまな問題

私は6か月以上私を苦しめている問題をServerFaultにもたらしています。 2 x Samsung 840 Pro SSD（512GB）を備えたmdソフトウェアRAID-1アレイを備えたCentOS 6（64ビット）サーバーがあります。

問題：

  • 深刻な書き込み速度の問題：
 root [〜] ＃time dd if = Arch.tar.gz of = test4 bs = 2M oflag = sync 
 146 +1レコードイン
 146 +1レコードアウト
 307191761バイト（307 MB）コピー、23.6788秒、13.0MB /秒
 
実際の0m23.680s 
ユーザー0m0.000s 
 sys 0m0.932s

  • 上記（または他のより大きなコピー）を実行すると、負荷は信じられないほどの値（100を超える場合でも）に急上昇し、約1から増加します。

  • 上記を実行すると、非常に奇妙なiostatの結果にも気づきました。

デバイス：rrqm/s wrqm/sr/sw/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm％util 
 sda 0.00 1589.50 0.00 54.00 0.00 13148.00 243.48 0.60 11.17 0.46 2.50 
 sdb 0.00 1627.50 0.00 16.50 0.00 9524.00 577.21 144.25 1439.33 60.61 100.00 
 md1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 
 md2 0.00 0.00 0.00 1602.00 0.00 12816.00 8.00 0.00 0.00 0.00 0.00 
 md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

そして、実際にファイルをデバイスに書き込むまで（スワップ/キャッシュ/メモリから）、この方法で保持します。

問題は、アレイ内の2番目のSSDにsvctmがあり、2番目のSSDの約100倍の大きさで待機することです。

  • 何らかの理由で、アレイの2つのメンバー間で摩耗が異なります
 root [〜] ＃smartctl --attributes/dev/sda | grep -i wear 
 177 Wear_Leveling_Count 0x0013 094％094000事前失敗常に-180 
 root [〜] ＃smartctl --attributes/dev/sdb | grep -i wear 
 177 Wear_Leveling_Count 0x0013 070％070000事前失敗常に-1005

最初のSSDの摩耗は6％で、2番目のSSDの摩耗は30％です!!

これは、アレイの2番目のSSDが、iostatの最初の反復（再起動後の平均）で証明されているように、最初のSSDの少なくとも5倍のハードで動作するようなものです。

デバイス：rrqm/s wrqm/sr/sw/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm％util 
 sda 10.44 51.06 790.39 125.41 8803.98 1633.11 11.40 0.33 0.37 0.06 5.64 
 sdb 9.53 58.35 322.37 118.11 4835.59 1633.11 14.69 0.33 0.76 0.29 12.97 
 md1 0.00 0.00 1.88 1.33 15.07 10.68 8.00 0.00 0.00 0.00 0.00 
 md2 0.00 0.00 1109.02 173.12 10881.59 1620.39 9.75 0.00 0.00 0.00 
 md0 0.00 0.00 0.41 0.01 3.10 0.02 7.42 0.00 0.00 0.00 0.00
  • 私が試したこと：ファームウェアをDXM05B0Qに更新しました（この更新後の840Pの劇的な改善の報告に続きます）。ケーブル/バックプレーンの問題をチェックするためにdmesgで「ハードリセットリンク」を探しましたが、何もありません。アラインメントを確認しましたが、正しくアラインメントされていると思います（1MB境界、以下のリスト）/ proc/mdstatをチェックし、配列は最適です（以下の2番目のリスト）。
ルート[〜] ＃fdisk -ul/dev/sda
ディスク/dev/sda：512.1 GB、512110190592バイト
 255ヘッド、63セクター/トラック、62260シリンダー、合計1000215216セクター
ユニット= 1のセクター* 512 = 512バイト
セクターサイズ（論理/物理）：512バイト/ 512バイト
 I/Oサイズ（最小/最適）：512バイト/ 512バイト
ディスク識別子：0x00026d59 
 
 Device Boot Start End Blocks Id System 
/dev/sda1 2048 4196351 2097152 fd Linux raid autodetect 
 Partition1はシリンダー境界で終了しません。
/dev/sda2 * 4196352 4605951 204800 fd Linux raid autodetect 
パーティション2はシリンダー境界で終了しません。
/dev/sda3 4605952 814106623 404750336 fd Linux raid autodetect 
 
 
ルート[〜] ＃fdisk -ul/dev/sdb
ディスク/dev/sdb：512.1 GB、512110190592バイト
 255ヘッド、63セクター/トラック、62260シリンダー、合計1000215216セクター
ユニット= 1のセクター* 512 = 512バイト
セクターサイズ（論理/物理）：512バイト/ 512バイト
 I/Oサイズ（最小/最適）：512バイト/ 512バイト
ディスク識別子：0x0003dede 
 
デバイスブート開始終了ブロックIDシステム
/dev/sdb1 2048 4196351 2097152 fdLinuxレイド自動検出
パーティション1はシリンダー境界で終了しません。
/dev/sdb2 * 4196352 4605951 204800 fd Linux raid autodetect 
パーティション2はシリンダー境界で終了しません。
/dev/sdb3 4605952 814106623 404750336 fd Linux raid autodetect 

/ proc/mdstat
 root＃cat /proc/mdstat
パーソナリティ：[raid1] 
 md0：アクティブraid1 sdb2 [1] sda2 [0] 
 204736ブロックスーパー1.0 [2/2] [UU] 
 
 md2：アクティブraid1 sdb3 [1] sda3 [0] 
 404750144ブロックスーパー1.0 [2/2] [UU] 
 
 md1：アクティブraid1 sdb1 [1] sda1 [0] 
 2096064ブロックスーパー1.1 [2/2] [UU] 
 
未使用デバイス：
  • Hdparmで読み取りテストを実行する
 root [〜] ＃hdparm -t /dev/sda
/dev/sda:
バッファリングされたディスク読み取りのタイミング：3.00秒で664 MB = 221.33MB /秒
 
 root [〜] ＃hdparm -t /dev/sdb
/dev/sdb:
バッファリングされたディスク読み取りのタイミング：3.01秒で288 MB = 95.77MB /秒
  • しかし、-directを追加するとどうなるか見てみましょう
 root [〜] ＃hdparm --direct -t /dev/sda

/dev/sda:
タイミングO_DIRECTディスク読み取り：3.01秒で788 MB = 262.08MB /秒
 root [〜] ＃hdparm --direct -t /dev/sdb

/dev/sdb:
タイミングO_DIRECTディスク読み取り： 3.02秒で534MB = 176.90MB /秒

両方のテストは増加しますが、/ dev/sdbは2倍になり、/ dev/sdaはおそらく20％増加します。これをどうすればいいのかわからない。

  • ワーグナー氏が提案したように、今回はddを使用して別の読み取りテストを実行しました。これにより、hdparmテストが確認されます。
 root [/ home2] ＃dd if =/dev/sda of =/dev/null bs = 1G count = 10 
 10 +0レコード入力
 10 +0レコード出力
 10737418240バイト（11 GB）コピー、38.0855秒、282 MB/s 
 
 root [/ home2] ＃dd if =/dev/sdb of =/dev/null bs = 1Gカウント= 10 
 10 +0レコード入力
 10 +0レコード出力
 10737418240バイト（11 GB）コピー、115.24秒、93.2MB /秒

したがって、sdaはsdbの3倍高速です。あるいは、sdbがsdaの機能以外のことも行っているのかもしれません。 sdbがsdaよりも多くのことを行っているかどうかを確認する方法はありますか？

  • 更新

繰り返しになりますが、ワーグナー氏が提案したように、私は2つのSSDを交換しました。そして彼がそれが起こるだろうと思ったので、問題はsdbからsdaに移りました。だから私はSSDの1つをRMAするだろうと思います。ケージに問題があるのではないかと思います。

この配列の何が問題になっていますか？助けてください！

performancesoftware-raidssdraid1md
2
Andy B

結局のところ、問題の少なくとも大部分を発見したと思います。アレイ内のSSDの1つが本当にひどく機能していたのです。 Samsung 840 Pro SSDに関するmdraidのパフォーマンスが低いという報告を十分に読みましたが、このドライブを単独で使用しても機能が非常に悪くなりました。とりあえず、hdparmを使って問題のSSDを安全に消去することで修正しました。パフォーマンスは自慢するものではありませんが、以前よりもまともなものにはるかに近くなっています。読み取りは約210〜220MB /秒、書き込みは約130〜150MB /秒です（以前の書き込みは5〜10MB /秒でした）。これは、最高速度が約240MB/sのSATA2であることに注意してください。

最後に、ドライブを交換するようアドバイスしてくれたワグナー氏に感謝します。

結論として、SSDでパフォーマンスの問題が発生した場合は、安全な消去を検討してください。安全な消去はフォーマットと同じではないことに注意してください。

0
Andy B