☰

8 台の SSD ドライブのソフトウェア RAID10 アレイの書き込みパフォーマンスが低い

tag-icon • tag-icon linux raid storage software-raid ssd
8 台の SSD ドライブのソフトウェア RAID10 アレイの書き込みパフォーマンスが低い

私はSupermicro X10DRW-iマザーボードと8台のKINGSTON SKC400S SSDのRAID10アレイを搭載したサーバーを所有しています。OSはCentOS 6です。

  # cat /proc/mdstat 
Personalities : [raid10] [raid1] 

md2 : active raid10 sdj3[9](S) sde3[4] sdi3[8] sdd3[3] sdg3[6] sdf3[5] sdh3[7] sdb3[1] sda3[0]
      3978989568 blocks super 1.1 512K chunks 2 near-copies [8/8] [UUUUUUUU]
      bitmap: 9/30 pages [36KB], 65536KB chunk

—

  # mdadm --detail /dev/md2                
    /dev/md2:
            Version : 1.1
      Creation Time : Wed Feb  8 18:35:14 2017
         Raid Level : raid10
         Array Size : 3978989568 (3794.66 GiB 4074.49 GB)
      Used Dev Size : 994747392 (948.67 GiB 1018.62 GB)
       Raid Devices : 8
      Total Devices : 9
        Persistence : Superblock is persistent

      Intent Bitmap : Internal

        Update Time : Fri Sep 14 15:19:51 2018
              State : active 
     Active Devices : 8
    Working Devices : 9
     Failed Devices : 0
      Spare Devices : 1

             Layout : near=2
         Chunk Size : 512K

               Name : ---------:2  (local to host -------)
               UUID : 8a945a7a:1d43dfb2:cdcf8665:ff607a1b
             Events : 601432

        Number   Major   Minor   RaidDevice State
           0       8        3        0      active sync set-A   /dev/sda3
           1       8       19        1      active sync set-B   /dev/sdb3
           8       8      131        2      active sync set-A   /dev/sdi3
           3       8       51        3      active sync set-B   /dev/sdd3
           4       8       67        4      active sync set-A   /dev/sde3
           5       8       83        5      active sync set-B   /dev/sdf3
           6       8       99        6      active sync set-A   /dev/sdg3
           7       8      115        7      active sync set-B   /dev/sdh3

           9       8      147        -      spare   /dev/sdj3

書き込み速度がひどく、SSD のパフォーマンスにまったく遠く及ばないことに気づきました。

# dd if=/dev/zero of=/tmp/testfile bs=1G count=1 oflag=dsync      
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied, 16.511 s, 65.0 MB/s

読み取り速度は問題ありません

# hdparm -tT /dev/md2

/dev/md2:
 Timing cached reads:   20240 MB in  1.99 seconds = 10154.24 MB/sec
 Timing buffered disk reads: 3478 MB in  3.00 seconds = 1158.61 MB/sec

この問題についてトラブルシューティングを行った結果、おそらく最初にストレージ構成を間違えたことがわかりました。X10DRW-i には、6 ポート SATA と 4 ポート sSATA の 2 つの独立した SATA コントローラを備えた Intel C610 が搭載されています。そのため、アレイ内のディスクは異なるコントローラに接続されており、これがパフォーマンス低下の根本原因であると考えています。この問題を解決するには、PCIe SAS コントローラ (おそらく AOC-S3008L-L8E) をインストールし、SSD ドライブを接続するしかありません。

そこで、次のことを確認したいと思います。

根本的な原因について私が正しいのでしょうか、それとも何かをもう一度確認する必要があるのでしょうか?

私の解決策は機能するでしょうか?

ドライブを新しいコントローラに再接続すると、RAID とデータは存続しますか? 調査したところ、パーティションの UUID は同じままなので、存続するようです。ただ、確認したいだけです。

皆様、予め感謝申し上げます。

UPD: iostat -x 1dd テストの実行中:https://pastebin.com/aTfRYriU

# hdparm /dev/sda                                    

/dev/sda:
 multcount     = 16 (on)
 IO_support    =  1 (32-bit)
 readonly      =  0 (off)
 readahead     = 256 (on)
 geometry      = 124519/255/63, sectors = 2000409264, start = 0

—

# cat /sys/block/md2/queue/scheduler                 
none

私の知る限り、スケジューラは物理ドライブ上に設定されていますが、

# cat /sys/block/sda/queue/scheduler 
noop anticipatory [deadline] cfq

—

smartctl -a(パーティションではなくデバイス上):https://pastebin.com/HcBp7gUH

UPD2:

# dd if=/dev/zero of=/tmp/testfile bs=1M count=1024 oflag=direct
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 14.389 s, 74.6 MB/s

UPD3:

fstrim/パーティションで実行したところ、いくつかの効果はありますが、書き込み速度はまだ低すぎます: 5 回連続のテストで 227 MB/秒、162 MB/秒、112 MB/秒、341 MB/秒、202 MB/秒。

答え1

測定されたパフォーマンスが低いのは、さまざまな要因の結果です。

  • 作成後、アレイは完全に同期され、半分の SSD にフラッシュ データ ページの大部分 (すべてではない) が割り当てられます。これにより、セキュア消去/トリムによってすべて/ほとんど/一部のページが「解放」されるまで、SSD のパフォーマンスは低下します。これにより、fstrim;後にパフォーマンスが向上することが説明されます。
  • (デフォルトの) 512 KB のチャンク サイズは、最大のシーケンシャル/ストリーミング パフォーマンスを得るには大きすぎます ( でベンチマークdd)。すべて SSD のアレイでは、64 KB のチャンク サイズを選択し、おそらく (ただし、実際のテストで確認する必要があります)、「far」レイアウトを使用します。チャンク サイズを小さくすると、ストリーミング アクセスには有利ですが、ランダム読み取り/書き込みに悪影響を与える可能性があることに注意してください。これは主に HDD の問題ですが、SSD でも多少影響を受ける可能性があります。
  • デフォルトでは、Linuxカーネルは最大512KBサイズのI/Oを発行します。つまり、1GBddブロックの使用を要求した場合でも（最初のコマンドのように）、これらは512KBサイズのリクエストに分割されます。512KBサイズのチャンクと組み合わせると、書き込み要求ごとに 1 つの SSD、基本的にストリーミング書き込みパフォーマンスを単一 SSD レベルで制限し、RAID による潜在的な速度向上を拒否します。max_sectors_kbで見つかった調整可能パラメータを使用することもできますが/sys/block/sdX/queue/max_sectors_kb、512 KB を超える値は (構成/カーネル バージョンによっては) 無視される可能性があります。
  • 最後に、興味深く、必須の最初のステップではありますが、ddそれ自体は貧弱なベンチマークです。これは、低い (1) キュー深度でのストリーミング パフォーマンスのみをテストします。現在のアレイ構成でも、より包括的なテストを行うと、fio少なくともランダム I/O では、単一ディスク シナリオに比べてパフォーマンスが大幅に向上することが示されます。

現在の状況を改善するために何ができるでしょうか？まず、しなければならないディスク/アレイを消去することを受け入れます。明らかに、必要最初のステップとしてバックアップを取ります。次に:

  • 配列を停止して削除する（mdadm -S /dev/md2）
  • トリム全てデータブロックオンどれでもディスク（blkdiscard /dev/sdX3）
  • 64KBのチャンクで配列を再作成し、クリーンフラグ （mdadm --create /dev/md2 --level=10 --raid-devices=8 --chunk=64 --assume-clean /dev/sdX3）
  • ddおよびで再ベンチしますfio。
  • すべてが正常であれば、バックアップを復元します。

SATA セットアップに関する最後の注意: 最高のパフォーマンスを得るためには、この方法でディスクを分割することは明らかに避けるべきです。とはいえ、書き込み速度が非常に遅いので、SATA コントローラーを責めることはできません。新しいものを購入する前に、上記の手順に従ってアレイを再作成することをお勧めします。

関連情報