☰

SSD 드라이브 8개로 구성된 소프트웨어 RAID10 어레이의 쓰기 성능 저하

tag-icon • tag-icon linux raid storage software-raid ssd
SSD 드라이브 8개로 구성된 소프트웨어 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에는 두 개의 별도 SATA 컨트롤러, 6포트 SATA 및 4포트 sSATA가 있는 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

AFAIK 스케줄러가 물리적 드라이브에 설정되어 있지만:

# 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회 연속 테스트에서 쓰기 속도가 227MB/s, 162MB/s, 112MB/s, 341MB/s, 202MB/s로 여전히 너무 느립니다.

답변1

측정된 낮은 성능은 다양한 요인의 결과입니다.

  • 생성 후 어레이가 완전히 동기화되어 SSD의 절반에 대부분의(전부는 아니지만) 플래시 데이터 페이지가 할당됩니다. 이렇게 하면 보안 삭제/트림으로 전체/대부분/일부 페이지가 "해제"될 때까지 SSD가 낮은 성능 상태로 전환됩니다. 이는 ; 이후의 성능 향상을 설명합니다 fstrim.
  • (기본값) 512KB 청크 크기는 최대 순차/스트리밍 성능에 비해 너무 큽니다( 벤치마킹 결과 dd). SSD로만 구성된 어레이에서는 64KB 청크 크기를 선택하고 아마도(그러나 이는 실제 테스트를 통해 확인해야 함) "원거리" 레이아웃을 선택합니다. 청크 크기를 줄이는 것은 스트리밍 액세스에 유익하지만 임의 읽기/쓰기에 불이익을 줄 수 있습니다. 이는 주로 HDD의 문제이지만 SSD도 어느 정도 영향을 받을 수 있습니다.
  • 기본적으로 Linux 커널은 최대 512KB 크기의 I/O를 발행합니다. 즉, dd첫 번째 명령에 따라 1GB 블록을 사용하도록 요청하더라도 이러한 블록은 수많은 512KB 크기 요청으로 분할됩니다. 512KB 크기의 청크와 결합하면쓰기 요청당 단일 SSD, 기본적으로 단일 SSD 수준에서 스트리밍 쓰기 성능을 제한하고 RAID로 인한 잠재적인 속도 증가를 거부합니다. max_sectors_kb튜너블( 에 있음 ) 을 사용할 수 있지만 /sys/block/sdX/queue/max_sectors_kb512KB보다 큰 값은(일부 구성/커널 버전에서) 무시될 수 있습니다.
  • 마지막으로 흥미롭고 의무적인 첫 번째 중지이지만 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 컨트롤러를 비난할 수 없습니다. 나는 새로운 것을 구입하기 전에 위의 지침에 따라 배열을 다시 만들 것입니다.

관련 정보