☰

Bajo rendimiento de escritura del software RAID10 de 8 unidades SSD

tag-icon • tag-icon linux raid storage software-raid ssd
Bajo rendimiento de escritura del software RAID10 de 8 unidades SSD

Tengo un servidor con placa base Supermicro X10DRW-i y una matriz RAID10 de 8 SSD KINGSTON SKC400S; El sistema operativo es 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

He notado que la velocidad de escritura es simplemente terrible, ni siquiera cerca del rendimiento de 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

Aunque la velocidad de lectura está bien

# 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

Después de solucionar un poco el problema, descubrí que probablemente había estropeado la configuración de almacenamiento inicialmente: X10DRW-i tiene Intel C610 que tiene dos controladores SATA separados, SATA de 6 puertos y sSATA de 4 puertos. Entonces, los discos en la matriz están conectados a diferentes controladores y creo que esta es la causa principal del bajo rendimiento. Sólo tengo una idea para solucionar este problema: instalar el controlador PCIe SAS (probablemente AOC-S3008L-L8E) y conectarle unidades SSD.

Entonces me gustaría confirmar lo siguiente:

¿Estoy en lo cierto acerca de la causa raíz o debería volver a verificar algo?

¿Funcionará mi solución?

Si vuelvo a conectar las unidades al nuevo controlador, ¿sobrevivirán mi RAID y mis datos? Mi investigación muestra que sí, ya que los UUID de las particiones seguirán siendo los mismos, pero solo quiero estar seguro.

Gracias a todos por adelantado.

UPD: iostat -x 1mientras realiza la prueba 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

Aunque el programador AFAIK está configurado en unidades físicas:

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

—

smartctl -a(en dispositivos, no en particiones):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:

Acabo de ejecutar fstrim/partition y obtuvealgunoEn efecto, la velocidad de escritura sigue siendo demasiado baja: 227 MB/s, 162 MB/s, 112 MB/s, 341 MB/s, 202 MB/s en cinco pruebas consecutivas.

Respuesta1

El bajo rendimiento medido es el resultado de varios factores:

  • Después de la creación, la matriz está completamente sincronizada, lo que provoca la asignación de la mayoría (si no todas) de las páginas de datos flash en la mitad de los SSD. Esto pondrá los SSD en un estado de bajo rendimiento hasta que un borrado/recorte seguro "libera" todas/la mayoría/algunas páginas. Esto explica el aumento del rendimiento después de un fstrim;
  • el tamaño de fragmento (predeterminado) de 512 KB es demasiado para un rendimiento secuencial/de transmisión máximo (como se compara con dd). Con una matriz totalmente SSD, seleccionaría un tamaño de fragmento de 64 KB y, probablemente (pero esto debería confirmarse con una prueba del mundo real), con un diseño "lejano". Tenga en cuenta que disminuir el tamaño del fragmento, si bien es beneficioso para los accesos de transmisión, puede penalizar las lecturas/escrituras aleatorias. Esto es una preocupación principalmente con los HDD, pero incluso los SSD pueden verse algo afectados;
  • De forma predeterminada, el kernel de Linux emite como máximo E/S de 512 KB. Esto significa que, incluso cuando solicite ddel uso de bloques de 1 GB (según su primer comando), estos se dividirán en una miríada de solicitudes de 512 KB. Junto con su fragmento de 512 KB, esto atraerá unaSSD único por solicitud de escritura, básicamente limita el rendimiento de escritura en streaming a nivel de un solo SSD y niega cualquier posible aumento de velocidad debido a RAID. Si bien puede utilizar el max_sectors_kboptimizable (que se encuentra en /sys/block/sdX/queue/max_sectors_kb), los valores superiores a 512 KB pueden (en algunas versiones de configuración/kernel) ignorarse;
  • Finalmente, si bien es interesante y una primera parada obligatoria, dden sí mismo es un punto de referencia deficiente: solo prueba el rendimiento de la transmisión con una profundidad de cola baja (1). Incluso con su configuración de matriz actual, una prueba más completa fiomostraría un aumento significativo del rendimiento en relación con un escenario de un solo disco, al menos en E/S aleatorias.

¿Qué puedes hacer para corregir la situación actual? Primero que nada, tudebeacepte borrar los discos/matriz; obviamente tunecesidadrealizar copias de seguridad como primer paso. Entonces:

  • detener y eliminar la matriz ( mdadm -S /dev/md2)
  • recortartodobloques de datos encualquierdisco ( blkdiscard /dev/sdX3)
  • recrear la matriz con fragmentos de 64 KB y con ellimpiobandera ( mdadm --create /dev/md2 --level=10 --raid-devices=8 --chunk=64 --assume-clean /dev/sdX3)
  • volver a bancar con ddy fio;
  • Si todo se ve bien, restaure su copia de seguridad.

Una última nota sobre su configuración SATA: claramente se debe evitar dividir el disco de esta manera para obtener el máximo rendimiento. Dicho esto, tu velocidad de escritura es tan baja que no culparía a tu controlador SATA. Realmente recrearía la matriz según las instrucciones anteriores antes de comprar algo nuevo.

información relacionada