Desempenho de gravação deficiente do conjunto de RAID10 de software de 8 unidades SSD

Question

Tenho servidor com placa-mãe Supermicro X10DRW-i e matriz RAID10 de 8 SSDs KINGSTON SKC400S; OS é o 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

Tenho notado que a velocidade de gravação é simplesmente terrível, nem perto do desempenho do 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

A velocidade de leitura está boa embora

# 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

Depois de solucionar o problema, descobri que provavelmente estraguei a configuração de armazenamento inicialmente: o X10DRW-i tem o Intel C610 que tem dois controladores SATA separados, SATA de 6 portas e sSATA de 4 portas. Portanto, os discos na matriz são conectados a diferentes controladores e acredito que essa seja a causa raiz do baixo desempenho. Eu tenho apenas uma idéia de consertar isso: instalar o controlador PCIe SAS (provavelmente AOC-S3008L-L8E) e conectar unidades SSD a ele.

Por isso, gostaria de confirmar o seguinte:

Estou certo sobre a causa raiz ou devo verificar novamente alguma coisa?

Minha solução funcionará?

Se eu reconectar as unidades ao novo controlador, meu RAID e os dados sobreviverão? Minha pesquisa mostra que sim, como UUIDs de partições permanecerão as mesmas, mas eu só quero ter certeza.

Obrigado a todos antecipadamente.

UPD: iostat -x 1 durante a realização do teste dd: link

# 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

Embora o agendador do AFAIK esteja configurado em unidades físicas:

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

-

smartctl -a (em dispositivos, não em partições): link

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:

Acabei de executar fstrim em / partition e obtive algum efeito, ainda a velocidade de gravação é muito baixa: 227 MB / s, 162 MB / s, 112 MB / s, 341 MB / s, 202 MB / s em cinco testes consecutivos.

    

Answer 1

O baixo desempenho medido é resultado de vários fatores:

• após a criação, o array é totalmente sincronizado, causando a alocação da maioria das páginas de dados em flash (se não todas) em metade dos SSDs. Isso colocará os SSDs em um estado de baixo desempenho até que um apagamento / ajuste seguro "libere" todas / a maioria / algumas páginas. Isso explica o aumento no desempenho após um fstrim ;
• o tamanho do bloco de 512 KB (padrão) é muito para o desempenho sequencial / de streaming máximo (como comparado com dd ). Com uma matriz all-SSDs eu selecionaria um tamanho de bloco de 64 KB e, provavelmente (mas isso deveria ser confirmado com um teste do mundo real), com layout "distante". Observe que diminuir o tamanho do fragmento, embora seja benéfico para acessos de streaming, pode penalizar leituras / gravações aleatórias. Isto é principalmente uma preocupação com os HDDs, mas mesmo os SSDs podem ser um pouco afetados;
• por padrão, o kernel do linux emite no máximo I / O de 512 KB. Isso significa que, mesmo ao solicitar que dd use blocos de 1 GB (conforme o primeiro comando), eles serão divididos em uma infinidade de solicitações de 512 KB. Juntamente com o seu pedaço de 512 KB, isso envolverá um SSD único por solicitação de gravação , basicamente limitando o desempenho de gravação em fluxo no nível SSD único e negando qualquer aumento de velocidade potencial devido ao RAID. Embora você possa usar o max_sectors_kb sintonizável (encontrado em /sys/block/sdX/queue/max_sectors_kb ), valores maiores que 512 podem (em algumas versões de configuração / kernel) ser ignorados;
• finalmente, embora interessante e obrigatória em primeira parada, o dd em si é um benchmark fraco: ele testa somente o desempenho do fluxo em baixa (1) profundidade da fila. Mesmo com sua configuração atual de array, um teste mais abrangente como fio mostraria um aumento de desempenho significativo em relação a um cenário de disco único, pelo menos em E / S aleatória.

O que você pode fazer para corrigir a situação atual? Primeiro de tudo, você deve aceitar limpar os discos / array; Obviamente, você precisa para fazer backups como primeiro passo. Então:

• pare e exclua a matriz ( mdadm -S /dev/md2 )
• trim todos blocos de dados em qualquer disco ( blkdiscard /dev/sdX3 )
• recrie a matriz com blocos de 64 KB e com o sinalizador clean ( mdadm --create /dev/md2 --level=10 --raid-devices=8 --chunk=64 --assume-clean /dev/sdX3 )
• re-bench com dd e fio ;
• se tudo estiver bem, restaure seu backup.

Uma última nota sobre sua configuração SATA: a divisão do disco dessa maneira deve ser claramente evitada para obter a máxima performance. Dito isto, sua velocidade de gravação é tão baixa que eu não culparia seu controlador SATA. Eu realmente recriaria a matriz por instrução acima antes de comprar qualquer coisa nova.