Server Support Forum
Hetzner Server langsame SSD

Zurück   Server Support Forum > >


Antwort
 
Themen-Optionen Thema bewerten
  #1  
Alt 10.11.2017, 16:45
Benutzerbild von Vengance
Vengance Vengance ist offline
Registered User
 
Registriert seit: 04.2016
Beiträge: 78
Hetzner Server langsame SSD

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.

Code:
~ # 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

Geändert von Vengance (10.11.2017 um 16:53 Uhr)
Mit Zitat antworten

  #2  
Alt 10.11.2017, 17:03
greystone greystone ist offline
Registered User
 
Registriert seit: 05.2016
Beiträge: 244
Das ist jetzt wirklich nicht so viel.

Hier ist mal die SSD im User-Benchmark:

http://ssd.userbenchmark.com/SpeedTe...-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...tion_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:

Code:
lsblk -o NAME,MOUNTPOINT,PHY-SEC
Blockgrösse des Dateisytems(bei ext4):

Code:
 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.

Geändert von greystone (10.11.2017 um 17:32 Uhr)
Mit Zitat antworten
  #3  
Alt 10.11.2017, 18:45
Benutzerbild von Vengance
Vengance Vengance ist offline
Registered User
 
Registriert seit: 04.2016
Beiträge: 78
Hi,

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

Code:
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


Code:
tune2fs -l /dev/mapper/vg0-root | grep -i "block size"
Block size:               4096
Mit Zitat antworten
  #4  
Alt 10.11.2017, 21:36
andreas0 andreas0 ist offline
Registered User
 
Registriert seit: 09.2009
Beiträge: 379
Zitat:
Zitat von Vengance Beitrag anzeigen
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:

Code:
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.
__________________
Umfrage: Wahl zwischen einem virtuellen und einem echten dedizierten Server
Homepage: Meine IP-Adresse - http://www.ip-a.de
Mit Zitat antworten
  #5  
Alt 11.11.2017, 08:15
ThomasChr ThomasChr ist offline
Registered User
 
Registriert seit: 08.2014
Beiträge: 336
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:
Code:
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
Mit Zitat antworten
  #6  
Alt 11.11.2017, 12:04
PHP-Friends PHP-Friends ist offline
verifizierter Anbieter
 
Registriert seit: 08.2014
Ort: Oberhausen
Beiträge: 584
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.
__________________
PHP-Friends | vollvirtualisierte vServer
PHP-Friends GmbH | Ruhrorter Str. 55a | 46049 Oberhausen
Geschäftsführer Marvin Strauch, Tim Schneider
USt-IdNr. DE 301 459 640
Handelsregister Amtsgericht Duisburg, HRB 28335
E-Mail gl@php-friends.de
Telefon +49 201 857 938 01 | Fax +49 201 857 938 00
Mit Zitat antworten
  #7  
Alt 11.11.2017, 12:34
Benutzerbild von Vengance
Vengance Vengance ist offline
Registered User
 
Registriert seit: 04.2016
Beiträge: 78
Hi,

Der Write Cache der Festplatten ist aktiv.

Code:
# 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.
Code:
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.
Mit Zitat antworten
  #8  
Alt 11.11.2017, 12:37
ThomasChr ThomasChr ist offline
Registered User
 
Registriert seit: 08.2014
Beiträge: 336
Lief da evtl. noch ein RAID-Rebuild?
Eigentlich müsstest du mit iotop sehen können ob deine Platten auch ruhig sind momentan.
__________________
www.thomaschristlieb.de
Mit Zitat antworten
  #9  
Alt 11.11.2017, 12:42
andreas0 andreas0 ist offline
Registered User
 
Registriert seit: 09.2009
Beiträge: 379
Zitat:
Zitat von Vengance Beitrag anzeigen
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.
__________________
Umfrage: Wahl zwischen einem virtuellen und einem echten dedizierten Server
Homepage: Meine IP-Adresse - http://www.ip-a.de
Mit Zitat antworten
  #10  
Alt 11.11.2017, 12:45
Benutzerbild von Vengance
Vengance Vengance ist offline
Registered User
 
Registriert seit: 04.2016
Beiträge: 78
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.

Geändert von Vengance (11.11.2017 um 12:48 Uhr)
Mit Zitat antworten
  #11  
Alt 11.11.2017, 12:47
andreas0 andreas0 ist offline
Registered User
 
Registriert seit: 09.2009
Beiträge: 379
Zitat:
Zitat von ThomasChr Beitrag anzeigen
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:
Code:
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.
__________________
Umfrage: Wahl zwischen einem virtuellen und einem echten dedizierten Server
Homepage: Meine IP-Adresse - http://www.ip-a.de
Mit Zitat antworten
  #12  
Alt 11.11.2017, 12:51
ThomasChr ThomasChr ist offline
Registered User
 
Registriert seit: 08.2014
Beiträge: 336
@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...
__________________
www.thomaschristlieb.de
Mit Zitat antworten
  #13  
Alt 11.11.2017, 12:53
marce marce ist offline
Registered User
 
Registriert seit: 10.2009
Ort: Dettenhausen
Alter: 43
Beiträge: 1.348
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.
Mit Zitat antworten
  #14  
Alt 11.11.2017, 12:57
andreas0 andreas0 ist offline
Registered User
 
Registriert seit: 09.2009
Beiträge: 379
Zitat:
Zitat von ThomasChr Beitrag anzeigen
@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.
__________________
Umfrage: Wahl zwischen einem virtuellen und einem echten dedizierten Server
Homepage: Meine IP-Adresse - http://www.ip-a.de
Mit Zitat antworten
  #15  
Alt 11.11.2017, 13:04
Benutzerbild von Vengance
Vengance Vengance ist offline
Registered User
 
Registriert seit: 04.2016
Beiträge: 78
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.
Code:
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
Miniaturansicht angehängter Grafiken
Hetzner Server langsame SSD-tjbd6zf.png  
Mit Zitat antworten
Antwort

Lesezeichen

Stichworte
hetzner, ssd


Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist aus.
HTML-Code ist aus.

Gehe zu

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Mail Log Einträge Flashrider Mail 20 06.09.2012 16:57
Postfix Probleme mit ISPConfig3 redcoon Mail 0 09.03.2010 10:15
Fehlermeldung exit signal Segmentation fault (11) Anaconda55 Virtuelle Server 12 03.01.2009 06:59
Komische Log Einträge Gulaschkanone Dedizierte Server 1 17.06.2007 17:34
VirtualHost wurmi Virtuelle Server 7 01.10.2003 23:20


Hetzner Server langsame SSD
Hetzner Server langsame SSD
Hetzner Server langsame SSD Hetzner Server langsame SSD
Powered by vBulletin® Version 3.8.11 (Deutsch)
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2017 DragonByte Technologies Ltd.