☰

Schlechte Schreibleistung des Software-RAID10-Arrays aus 8 SSD-Laufwerken

tag-icon • tag-icon linux raid storage software-raid ssd
Schlechte Schreibleistung des Software-RAID10-Arrays aus 8 SSD-Laufwerken

Ich habe einen Server mit Supermicro X10DRW-i-Motherboard und RAID10-Array aus 8 KINGSTON SKC400S SSDs; Betriebssystem ist 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

Mir ist aufgefallen, dass die Schreibgeschwindigkeit einfach schrecklich ist und nicht einmal an die Leistung einer SSD heranreicht.

# 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

Die Lesegeschwindigkeit ist jedoch in Ordnung

# 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

Nachdem ich das Problem behoben hatte, stellte ich fest, dass ich wahrscheinlich zunächst die Speicherkonfiguration vermasselt hatte: X10DRW-i verfügt über Intel C610 mit zwei separaten SATA-Controllern, 6-Port SATA und 4-Port sSATA. Die Festplatten im Array sind also an unterschiedliche Controller angeschlossen, und ich glaube, dies ist die Hauptursache für die schlechte Leistung. Ich habe nur eine Idee, dies zu beheben: PCIe SAS-Controller installieren (wahrscheinlich AOC-S3008L-L8E) und SSD-Laufwerke daran anschließen.

Daher möchte ich Folgendes bestätigen:

Habe ich hinsichtlich der Grundursache recht oder sollte ich etwas noch einmal überprüfen?

Wird meine Lösung funktionieren?

Wenn ich Laufwerke wieder an einen neuen Controller anschließe, bleiben mein RAID und meine Daten erhalten? Meine Recherchen haben ergeben, dass dies der Fall ist, da die UUIDs der Partitionen gleich bleiben, aber ich möchte einfach sichergehen.

Vielen Dank im Voraus an alle.

UPD: iostat -x 1während der Durchführung des DD-Tests: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

Soweit ich weiß, ist der Scheduler jedoch auf physische Laufwerke eingestellt:

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

—

smartctl -a(auf Geräten, nicht auf Partitionen):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:

Ich habe es gerade fstrimauf / partition ausgeführt und bekammancheEffekt, immer noch ist die Schreibgeschwindigkeit zu niedrig: 227 MB/s, 162 MB/s, 112 MB/s, 341 MB/s, 202 MB/s in fünf aufeinanderfolgenden Tests.

Antwort1

Die gemessenen schlechten Leistungen sind das Ergebnis verschiedener Faktoren:

  • Nach der Erstellung wird das Array vollständig synchronisiert, was die Zuordnung der meisten (wenn nicht aller) Flash-Datenseiten auf die Hälfte der SSDs bewirkt. Dadurch werden die SSDs in einen Zustand geringer Leistung versetzt, bis ein sicheres Löschen/Trimmen alle/die meisten/einige Seiten „freigibt“. Dies erklärt die verbesserte Leistung nach einem fstrim;
  • die (standardmäßige) Blockgröße von 512 KB ist zu viel für maximale sequentielle/Streaming-Leistung (wie mit getestet dd). Bei einem reinen SSD-Array würde ich eine Blockgröße von 64 KB und wahrscheinlich (aber das sollte durch einen Praxistest bestätigt werden) ein „Far“-Layout wählen. Bitte beachten Sie, dass eine Verringerung der Blockgröße zwar für Streaming-Zugriffe vorteilhaft ist, aber zufällige Lese-/Schreibvorgänge beeinträchtigen kann. Dies ist hauptsächlich bei Festplatten ein Problem, aber auch SSDs können in gewissem Maße betroffen sein;
  • standardmäßig gibt der Linux-Kernel höchstens 512 KB große I/O-Vorgänge aus. Das bedeutet, dass selbst wenn Sie dd1 GB große Blöcke verwenden möchten (wie bei Ihrem ersten Befehl), diese in eine Vielzahl von 512 KB großen Anfragen aufgeteilt werden. Zusammen mit Ihrem 512 KB großen Block wird dies eineneinzelne SSD pro Schreibanforderung, wodurch die Streaming-Schreibleistung im Wesentlichen auf Einzel-SSD-Ebene begrenzt und jede mögliche Geschwindigkeitssteigerung durch RAID verhindert wird. Sie können zwar die max_sectors_kbanpassbare Option verwenden (zu finden in /sys/block/sdX/queue/max_sectors_kb), Werte über 512 KB können (in einigen Konfigurations-/Kernelversionen) jedoch ignoriert werden;
  • Schließlich ist es zwar interessant und ein obligatorischer erster Anlaufpunkt, aber ddselbst ein schlechter Benchmark: Es testet nur die Streaming-Leistung bei geringer (1) Warteschlangentiefe. Selbst mit Ihrer aktuellen Array-Konfiguration würde ein umfassenderer Test eine fiosignifikante Leistungssteigerung im Vergleich zu einem Szenario mit einer einzelnen Festplatte zeigen, zumindest bei zufälligem I/O.

Was können Sie tun, um die aktuelle Situation zu korrigieren? Zunächst einmalmussakzeptieren, die Festplatten/Arrays zu löschen; natürlichbrauchenals ersten Schritt Backups zu erstellen. Dann:

  • Stoppen und Löschen des Arrays ( mdadm -S /dev/md2)
  • trimmenalleDatenblöcke aufbeliebigScheibe ( blkdiscard /dev/sdX3)
  • Erstellen Sie das Array mit 64 KB-Blöcken neu und mit demsauberFlagge ( mdadm --create /dev/md2 --level=10 --raid-devices=8 --chunk=64 --assume-clean /dev/sdX3)
  • Neubesetzung mit ddund fio;
  • Wenn alles gut aussieht, stellen Sie Ihr Backup wieder her.

Eine letzte Anmerkung zu Ihrem SATA-Setup: Um eine maximale Leistung zu erzielen, sollten Sie das Aufteilen der Festplatte auf diese Weise unbedingt vermeiden. Allerdings ist Ihre Schreibgeschwindigkeit so niedrig, dass ich Ihrem SATA-Controller nicht die Schuld geben würde. Ich würde das Array wirklich gemäß der obigen Anleitung neu erstellen, bevor ich etwas Neues kaufe.

verwandte Informationen