Hetzner Server langsame SSD

[Vengance]

Hallo,

Ich habe kürzlich einen Hetzner Server aus der Serverbörse mit folgender Hardware bestellt:
- Intel Xeon E3-1246 v3
- 32GB DDR3 RAM
- 2x 256GB Micron M600 im Software Raid 1

Auf dem System läuft Proxmox 5.1 auf Debian Stretch basis.
Ich habe einige Benchmarks ausgeführt und mir ist aufgefallen, dass die SSDs mit rund 150MB/s sehr langsam sind.

Hat jemand eine Idee woran das liegen könnte? Das System ist soweit noch leer.

~ # dd if=/dev/zero of=testfile bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.95281 s, 154 MB/s
~ # dd if=/dev/zero of=testfile2 bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 8.96393 s, 120 MB/s
~ # dd if=/dev/zero of=testfile3 bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 8.6796 s, 124 MB/s

 

[greystone]

Das ist jetzt wirklich nicht so viel.

Hier ist mal die SSD im User-Benchmark:

http://ssd.userbenchmark.com/SpeedTest/24442/Micron-M600-MTFDDAK256MBF

D. h. da sollte eigentlich mehr gehen. Ich habe hier aber auch welche, die nicht ansatzweise auf Werte kommen, die dort gelistet sind.

Auch nochmal die Partitionsausrichtung prüfen. (Siehe hier: https://www.thomas-krenn.com/de/wiki/Partition_Alignment)

Und die Blockgrösse vom RAID und vom Dateisystem. Wenn die Blockgrösse geringer ist als die physikalische Blockgrösse der SSD, dann kann das als starke Bremse wirken. SW-RAID-Blocksize ist per default bei alten Systemen 64k, bei neueren noch grösser.

Beispiel

Hardwareblockgrösse ist 4 KiB. Softwareblockgrösse(RAID und/oder Dateisystem) ist 512 Bytes.

Das hat zur Folge, dass jeder logische 512-Byte Block als 4K(= da kleinste addressierbare Einheit der SSD) geschrieben wird. Das führt in dem Fall also dazu, dass ein Block 8x beschrieben wird.

-----

Physikalische Sektorgrösse ermitteln:

lsblk -o NAME,MOUNTPOINT,PHY-SEC

Blockgrösse des Dateisytems(bei ext4):

 tune2fs  -l /dev/ROOTPARTITION | grep -i "block size"

Im übrigen sind die Werte für ältere Platten/SSDs meist 512 Bytes und für neuere 4K.

 

[Vengance]

Hi,

Ich habe vergessen zu erwähnen, dass ich LVM auf dem System nutze, ändert das etwas an der Sache?

root@pve ~ # lsblk -o NAME,MOUNTPOINT,PHY-SEC
NAME                           MOUNTPOINT PHY-SEC
sda                                          4096
├─sda1                                       4096
│ └─md0                        /boot         4096
└─sda2                                       4096
  └─md1                                      4096
    ├─vg0-root                 /             4096
    ├─vg0-swap                 [SWAP]        4096
    ├─vg0-data_tmeta                         4096
    │ └─vg0-data-tpool                       4096
    │   ├─vg0-data                           4096
    │   ├─vg0-vm--101--disk--1               4096
    │   └─vg0-vm--166--disk--1               4096
    └─vg0-data_tdata                         4096
      └─vg0-data-tpool                       4096
        ├─vg0-data                           4096
        ├─vg0-vm--101--disk--1               4096
        └─vg0-vm--166--disk--1               4096
sdb                                          4096
├─sdb1                                       4096
│ └─md0                        /boot         4096
└─sdb2                                       4096
  └─md1                                      4096
    ├─vg0-root                 /             4096
    ├─vg0-swap                 [SWAP]        4096
    ├─vg0-data_tmeta                         4096
    │ └─vg0-data-tpool                       4096
    │   ├─vg0-data                           4096
    │   ├─vg0-vm--101--disk--1               4096
    │   └─vg0-vm--166--disk--1               4096
    └─vg0-data_tdata                         4096
      └─vg0-data-tpool                       4096
        ├─vg0-data                           4096
        ├─vg0-vm--101--disk--1               4096
        └─vg0-vm--166--disk--1               4096

tune2fs -l /dev/mapper/vg0-root | grep -i "block size"
Block size:               4096

 

[andreas0]

Ich habe einige Benchmarks ausgeführt und mir ist aufgefallen, dass die SSDs mit rund 150MB/s sehr langsam sind.

Du könntest mal mit dem Befehl "hdparm -W /Laufwerk" abfragen, ob der Cache des jeweiligen Laufwerks auch eingeschaltet ist.

Den Cache kannst du mit dem Befehl "hdparm -W1 /Laufwerk" auch nachträglich einschalten.

Auf einem virtuellen Server mit der Produktbezeichnung "RS 8000 SSD G7" mit SSDs im RAID 10 Verbund (Hardware-RAID) - laut den technischen Angaben vom Provider Netcup - sieht das Ergebnis bei einem Load Average von 0,00, 0,01, 0,05 wie folgt aus:

dd if=/dev/zero of=testfile bs=1G count=1 oflag=direct
1073741824 Bytes (1,1 GB) kopiert, 15,3039 s, 70,2 MB/s

Wenn also der Cache bei deinen SSDs ausgeschaltet ist, würde ich mal die von dir genannte Schreibleistung von 150MB/s im Gegensatz zur Schreibleistung des virtuellen Servers mit nur 70 MB/s als sehr gut bezeichnen, zumal du auf deinem Server nur ein Software-RAID 1 hast.

 

[ThomasChr]

Also das hier ist ein (idle) RS 4000 G7 SE von netcup mit SSDs, und diese Werte sind bei dem Server (zwischen 0.6 - 1.2 GB/s) normal:

root@server:~# dd if=/dev/zero of=testfile bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.987334 s, 1.1 GB/s

Wobei ich davon ausgehn würde dass die Geschwindigkeit aus dem Cache des Hardware-Raids kommt und wahrscheinlich nicht wirklich die Plattengeschwindigkeit darstellt. Nichtsdestotrotz, andreas0, scheint mit dein netcup Server außergewöhnlich langsam (bei diesem speziellem, syntetischen) Benchmark zu sein.
Ich bin ähnliche Werte wie oben von allen meinen netcup SSD Servern gewohnt. Afaik auch von den G7 ohne SE.

Thomas

 

[PHP-Friends]

Ich schließe mich ThomasChr grundsätzlich an, netcup ist - auch wenn ich nur für die aktuelle Generation sprechen kann - für eine gute I/O-Performance bekannt. Aber es ist nicht gesagt, dass es hier an netcup liegt. Mountoptionen und Partitionsalignment können große Auswirkungen haben, ebenso natürlich das verwendete Dateisystem. Du solltest die Tests daher auch im Rescue wiederholen, um herauszufinden, ob es ggf. an deinem spezifischen Setup liegt.

 

[Vengance]

Hi,

Der Write Cache der Festplatten ist aktiv.

# hdparm -W /dev/sda

/dev/sda:
 write-caching =  1 (on)
# hdparm -W /dev/sdb

/dev/sdb:
 write-caching =  1 (on)

Ich habe den I/O Test eben nochmal wiederholt und mir ist aufgefallen, dass die Performance im Vergleich zu gestern ein gutes Stück höher ist.

dd if=/dev/zero of=testfile25 bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.90054 s, 370 MB/s

Das merkwürdige ist aber, dass seit gestern an dem Server nichts verändert wurde und auch die Last seither identisch ist.

 

[ThomasChr]

Lief da evtl. noch ein RAID-Rebuild?
Eigentlich müsstest du mit iotop sehen können ob deine Platten auch ruhig sind momentan.

 

[andreas0]

Das merkwürdige ist aber, dass seit gestern an dem Server nichts verändert wurde und auch die Last seither identisch ist.

Eventuell hatte dein System zum Zeitpunkt deiner ersten Messung das RAID geprüft, was man mit dem Befehl "cat /proc/mdstat" während der Prüfung live sehen kann, was dann auch den Schreibvorgang verringert.

 

[Vengance]

Der RAID Rebuild war zu dem Zeitpunkt eigentlich schon lange fertig und die Platten waren soweit auch ruhig.
Mir ist damals über iotop aber aufgefallen, dass es starke Einbrüche bei der Schreibperformance gab, diese war nichtmal ansatzweise konstant wären dem Schreiben einer Datei mit DD.
Nun scheint das aber nichtmehr der Fall zu sein.

 

[andreas0]

Wobei ich davon ausgehn würde dass die Geschwindigkeit aus dem Cache des Hardware-Raids kommt und wahrscheinlich nicht wirklich die Plattengeschwindigkeit darstellt.

Das Problem mit dem störenden Hardware-RAID-Controller Cache kannst du geschickt dadurch umgehen, dass du zuvor Zufallszahlen (urandom) generieren läßt und dann die Daten häppchenweise (bs=1M count=1000) in die Testdatei reinschreiben läßt. Denn die Zufallszahlen sind garantiert jedes mal anders und liegen dem Cache noch nicht vor, was dann zur Folge hat, daß die schon vorhandene Testdatei auf dem Plattensystem zwangsweise durch eine neue Testdatei mit neuem Inhalt ersetzt werden muß.

Der Befehl und dessen Ergebnis sieht dann wie folgt:

dd if=/dev/urandom bs=1M count=1000 of=testfile oflag=direct
1019215872 Bytes (1,0 GB) kopiert, 11,112309 s, 91,7 MB/s

Auch dieser Befehl wurde auf dem schon zuvor genannten virtuellen Server - auch mit der Endung SE in der Produktbezeichnung - ausgeführt.

 

[ThomasChr]

@andreas0
Ob das Zufallsdaten sind oder nicht ist dem Hardware-Cache beim schreiben doch egal. Die Daten kommen im Hardwarecache an und dieser sagt 'fertig geschrieben' obwohl sie noch nicht auf der Platte liegen. Und da der Hardwarecache extern ist kann man das von einem vServer auch nicht beeinflussen.

Wann die Daten vom Hardwarecache dann tatsächlich auf die Platten kommen entscheided der Hardwarecache wie er es für richtig hält. Das Bestriebssystem hat einen sync() gemacht und aus Sicht des Betriebssystems sind die Daten auf der Platte...

 

[marce]

wobei man da mit ein wenig Pech eher die Performance von /dev/urandom testet als die des Plattensystems - gerade auf VMs.

Die beste Methode ist immer noch, nicht mit so "Witz-Dateien" von 1GB zu testen sondern direkt mal 10GB, 20GB, 50GB oder ähnliches rauszujagen - da hat man 'ne gute Chance, Größen zu erwischen, die jenseits aller Cache-Kapazitäten liegen. Gerade bei VMs gibt's auch immer noch das Hostsystem, wo ggf. auch noch zusätzlicher IO-Cache bereitgestellt wird.

Ok - leider ist dann ein Test auch nicht in 20s erledgt - aber irgendwas ist immer.

 

[andreas0]

@andreas0
Ob das Zufallsdaten sind oder nicht ist dem Hardware-Cache beim schreiben doch egal.

Probiere es einfach mal an Hand meines Befehls auf deinem Server aus.

 

[Vengance]

Was mir allerdings noch aufgefallen ist, das Klonen eines Templates in Proxmox erzeugt eine ziemlich hohes IO Wait von rund 40-50%.
Das obwohl das Template lediglich ein paar GB groß ist.
Siehe Anhang.

Die IO Performance ist auch wieder auf rud 160MB/s gesunken.

dd if=/dev/zero of=iotesty bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.60918 s, 162 MB/s

 

[PHP-Friends]

Teste die Platten mal einzeln mit hdparm; wenn eine SSD langsam stirbt, reißt sie den RAID-Verbund runter. Kommt insbesondere bei Desktop-SSDs häufiger vor, wobei ich die Produktpalette von Hetzner jetzt nicht mehr so genau kenne, also nicht weiß, ob in deinem Server nicht doch schon Datacenter-SSDs rennen.

 

[ThomasChr]

@andreas0
Was du misst ist CPU Geschwindigkeit.
Achte mal auf die Stacks beim dd mit /dev/urandom - die befinden sich in urandom_read, vfs_read - das sind (imho) Funktionen die viel vom Kernel virutellen Filesystem lesen und Berechnungen machen. Nichts was man machen will wenn man die Disk benchmarkt. Auch die Stats zeigen deutlich dass wir beim schreiben aus /dev/urandom, trotz um eine zehnerpotenz weniger Blöcke, das 52 Fache an Instruktionen der CPU durchführen. Bei einem I/O Benchmark möchte man keine CPU Instruktionen haben.
Auch die Stats von der Variante mit /dev/zero zeigt mehr auf Voluntary Context Switching (was bei I/O erwartet ist).

dd if=/dev/urandom bs=1M count=100 of=testfile oflag=direct:

+   98,90%     0,00%  dd           [kernel.kallsyms]   [k] entry_SYSCALL_64_fastpath
+   98,78%     0,00%  dd           [kernel.kallsyms]   [k] urandom_read
+   98,78%     0,00%  dd           [kernel.kallsyms]   [k] __vfs_read
+   98,78%     0,00%  dd           [kernel.kallsyms]   [k] vfs_read
+   98,78%     0,00%  dd           [kernel.kallsyms]   [k] sys_read
+   98,78%     0,00%  dd           libc-2.23.so        [.] read
+   97,08%     0,24%  dd           [kernel.kallsyms]   [k] extract_entropy_user
+   95,87%    36,00%  dd           [kernel.kallsyms]   [k] extract_buf
+   36,08%    36,08%  dd           [kernel.kallsyms]   [k] sha_transform
+   16,00%     0,49%  dd           [kernel.kallsyms]   [k] __mix_pool_bytes
+   15,74%    15,74%  dd           [kernel.kallsyms]   [k] _mix_pool_bytes

       8276,872332      task-clock (msec)         #    0,986 CPUs utilized          
               107      context-switches          #    0,013 K/sec                  
                 0      cpu-migrations            #    0,000 K/sec                  
               327      page-faults               #    0,040 K/sec                  
    23.832.173.442      cycles                    #    2,879 GHz                    
    37.787.332.621      instructions              #    1,59  insns per cycle        
       854.662.234      branches                  #  103,259 M/sec                  
           214.911      branch-misses             #    0,03% of all branches

	Command being timed: "dd if=/dev/urandom bs=1M count=100 of=testfile oflag=direct"
	User time (seconds): 0.00
	System time (seconds): 7.96
	Percent of CPU this job got: 99%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 0:08.03
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 3380
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 0
	Minor (reclaiming a frame) page faults: 342
	Voluntary context switches: 102
	Involuntary context switches: 7
	Swaps: 0
	File system inputs: 0
	File system outputs: 204800
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0

dd if=/dev/zero bs=1M count=1000 of=testfile oflag=direct:

+   52,29%     0,00%  dd            [kernel.kallsyms]   [k] entry_SYSCALL_64_fastpath
+   28,96%     0,00%  swapper       [kernel.kallsyms]   [k] start_secondary
+   28,91%     0,00%  swapper       [kernel.kallsyms]   [k] cpu_startup_entry
+   27,89%     0,00%  dd            [kernel.kallsyms]   [k] vfs_read
+   27,89%     0,00%  dd            [kernel.kallsyms]   [k] sys_read
+   27,89%     0,00%  dd            libc-2.23.so        [.] read
+   27,16%     0,00%  dd            [kernel.kallsyms]   [k] new_sync_read
+   27,16%     0,00%  dd            [kernel.kallsyms]   [k] __vfs_read
+   27,16%     1,36%  dd            [kernel.kallsyms]   [k] read_iter_zero
+   25,80%     3,06%  dd            [kernel.kallsyms]   [k] iov_iter_zero
+   25,35%     0,94%  dd            libc-2.23.so        [.] write
+   24,41%     0,76%  dd            [kernel.kallsyms]   [k] ext4_ind_direct_IO
+   24,41%     0,00%  dd            [kernel.kallsyms]   [k] ext4_direct_IO
+   24,41%     0,00%  dd            [kernel.kallsyms]   [k] generic_file_direct_write
+   24,41%     0,00%  dd            [kernel.kallsyms]   [k] __generic_file_write_iter
+   24,41%     0,00%  dd            [kernel.kallsyms]   [k] ext4_file_write_iter
+   24,41%     0,00%  dd            [kernel.kallsyms]   [k] new_sync_write

        157,367758      task-clock (msec)         #    0,200 CPUs utilized          
             1.002      context-switches          #    0,006 M/sec                  
                 0      cpu-migrations            #    0,000 K/sec                  
               328      page-faults               #    0,002 M/sec                  
       408.254.765      cycles                    #    2,594 GHz                     
       714.788.095      instructions              #    1,75  insns per cycle        
       168.030.796      branches                  # 1067,759 M/sec                  
           646.502      branch-misses             #    0,38% of all branches

	Command being timed: "dd if=/dev/zero bs=1M count=1000 of=testfile oflag=direct"
	User time (seconds): 0.00
	System time (seconds): 0.15
	Percent of CPU this job got: 14%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.04
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 3316
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 0
	Minor (reclaiming a frame) page faults: 342
	Voluntary context switches: 1001
	Involuntary context switches: 1
	Swaps: 0
	File system inputs: 0
	File system outputs: 2048000
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0

 

[andreas0]

@andreas0
Was du misst ist CPU Geschwindigkeit.

Ich habe meinen Befehl noch mal auf einem dedizierten Server mit SSDs und deutlich kleinerer CPU (E3-1230 v5) ausgeführt.

Das Ergebnis auf diesem Server sieht wie folgt aus:

dd if=/dev/urandom of=testfile bs=1M count=1024 oflag=direct
1022361600 Bytes (1,0 GB) kopiert, 5,020839 s, 204 MB/s

Aufgrund der weitaus kleineren CPU (E3-1230 v5) des dedizierten Servers gegenüber der CPU des Hostsystems (CPU E5-2680 v4, eventuell sogar x 2) beim Provider Netcup kann man für so einen Test die CPU-Last vernachlässigen.

 

[ThomasChr]

Trotzdem misst du da mehr CPU und Implementierung von Zufallszahlen als Plattengeschwindigket.
marce hat vollkommen Recht, du testest urandom. Und meine oberen Ausgaben (Context Switche, CPU Zyklen, Sampling der Stacks) zeigen das sehr deutlich.

PS: Und beim CPU Vergleich solltest du immer dran denken dass sowohl vCPUs als auch deren Bus auf dem Host geshared ist. Ein direkter Vergleich von vServer und dedi ist so nicht möglich.

 

[andreas0]

Die IO Performance ist auch wieder auf rud 160MB/s gesunken.

Du könntest deine Konfiguration in der fstab mal wie im folgendem Beispiel zu sehen anpassen. Eventuell wird es dann dadurch besser.

Beispiel:

UUID=Nummer-des-SoftwareRAIDs /meine-vms  ext4    defaults,noatime,lazytime,discard 1 2