☰

Baixo desempenho de gravação do software RAID10 de 8 unidades SSD

tag-icon • tag-icon linux raid storage software-raid ssd
Baixo desempenho de gravação do software RAID10 de 8 unidades SSD

Tenho servidor com placa-mãe Supermicro X10DRW-i e array RAID10 de 8 SSDs KINGSTON SKC400S; O sistema operacional é 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

Percebi 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 é boa

# 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 errei inicialmente a configuração de armazenamento: o X10DRW-i possui Intel C610 que possui dois controladores SATA separados, SATA de 6 portas e sSATA de 4 portas. Portanto, os discos do array estão conectados a controladores diferentes e acredito que essa seja a causa raiz do baixo desempenho. Só tenho uma ideia para consertar isso: instalar o controlador PCIe SAS (provavelmente AOC-S3008L-L8E) e conectar unidades SSD a ele.

Então, gostaria de confirmar o seguinte:

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

Minha solução funcionará?

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

Obrigado a todos antecipadamente.

UPD: iostat -x 1durante a execução do teste dd: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

Embora o agendador 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):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:

Acabei de executar fstrimem / partição e obtivealgunsefeito, a velocidade de gravação ainda é muito baixa: 227 MB/s, 162 MB/s, 112 MB/s, 341 MB/s, 202 MB/s em cinco testes consecutivos.

Responder1

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

  • após a criação, o array é totalmente sincronizado, causando a alocação da maioria (se não de todas) das páginas de dados flash em metade dos SSDs. Isso colocará os SSDs em um estado de baixo desempenho até que um apagamento/corte seguro "libere" todas/a maioria/algumas páginas. Isso explica o aumento do desempenho após um fstrim;
  • o tamanho do bloco (padrão) de 512 KB é demais para o desempenho máximo sequencial/streaming (conforme comparado com dd). Com uma matriz totalmente SSD, eu selecionaria um tamanho de bloco de 64 KB e, provavelmente (mas isso deve ser confirmado com testes do mundo real), com layout "distante". Observe que diminuir o tamanho do bloco, embora seja benéfico para acessos de streaming, pode penalizar leituras/gravações aleatórias. Esta é uma preocupação principalmente com HDDs, mas até mesmo SSDs podem ser um pouco afetados;
  • por padrão, o kernel do Linux emite E/S de no máximo 512 KB. Isso significa que, mesmo ao solicitar ddo uso de blocos de 1 GB (conforme seu primeiro comando), eles serão divididos em uma infinidade de solicitações de 512 KB. Juntamente com seu pedaço de 512 KB, isso envolverá umúnico SSD por solicitação de gravação, basicamente limitando o desempenho de gravação de streaming no nível de SSD único e negando qualquer aumento potencial de velocidade devido ao RAID. Embora você possa usar o max_sectors_kbajustável (encontrado em /sys/block/sdX/queue/max_sectors_kb), valores maiores que 512 KB podem (em algumas versões de configuração/kernel) ser ignorados;
  • finalmente, embora interessante e uma primeira parada obrigatória, ddele próprio é um benchmark ruim: ele apenas testa o desempenho do streaming em profundidade de fila baixa (1). Mesmo com a configuração atual do array, um teste mais abrangente mostraria um fioaumento significativo de desempenho 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? Em primeiro lugar, vocêdeveaceite limpar os discos/matriz; obviamente, vocêprecisarpara fazer backups como primeiro passo. Então:

  • pare e exclua o array ( mdadm -S /dev/md2)
  • aparartodosblocos de dados emqualquerdisco ( blkdiscard /dev/sdX3)
  • recrie a matriz com pedaços de 64 KB e com olimparbandeira ( mdadm --create /dev/md2 --level=10 --raid-devices=8 --chunk=64 --assume-clean /dev/sdX3)
  • re-banco com dde fio;
  • se tudo parecer bem, restaure seu backup.

Uma última observação sobre a configuração do SATA: a divisão do disco dessa maneira deve ser claramente evitada para obter o desempenho máximo. Dito isto, sua velocidade de gravação é tão baixa que eu não culparia seu controlador SATA. Eu realmente recriaria o array de acordo com as instruções acima antes de comprar algo novo.

informação relacionada