Server Support Forum
Welche Disk Latency ist denn so akzeptabel?

Zurück   Server Support Forum > >


Antwort
 
Themen-Optionen Thema bewerten
  #1  
Alt 06.01.2018, 17:57
tomcat8 tomcat8 ist offline
Registered User
 
Registriert seit: 05.2017
Beiträge: 10
Welche Disk Latency ist denn so akzeptabel?

Hallo,

Munin erzählt mir, dass meine Disk Latency im Minimum bei 7ms liegt, im Durchschnitt bei 120ms und das Maximum sind 2,8 Sekunden(!).
Das kommt mir doch etwas viel vor.
Das Ergebnis ist jedenfalls, dass ein eigentlich völlig unterbeschäftigtes System (6 CPU-Kerne, 18GB Speicher; Load liegt bei 0,1) trotzdem gelegentlich unbefriedigende Antwortzeiten liefert :-(

Jetzt habe ich mir einen Cache von 6GB gebaut (das sind etwa 5% der Daten), und kann so immerhin bei ca. 1/3 der Anfragen die Daten in 0,02ms bereitstellen.

Ein Umstieg auf SSD wäre doch recht teuer, und dann hätte ich noch mehr unterbeschäftigte CPU-Kerne :-|
Mit Zitat antworten

  #2  
Alt 06.01.2018, 19:34
Benutzerbild von d4f
d4f d4f ist offline
Support Guru
 
Registriert seit: 04.2007
Ort: /dev/urandom
Beiträge: 4.309
d4f eine Nachricht über ICQ schicken d4f eine Nachricht über MSN schicken
Zitat:
dass ein eigentlich völlig unterbeschäftigtes System
Sowohl CPU als auch RAM haben mit Disk-latency nur marginal zu tun. Die Disk latency ist, wie der Name schon sagt, nur die Festplattenauslastung und die kann auch hoch sein wenn der Rest des Rechners sich langweilt.

Bei virtuellen Server insbesondere kommt es gerne mal vor dass andere Teilnehmer die Festplatten so auslasten dass deine IO überlastet ist obwohl du selber nichts tust.

Mit bspw "iotop" und "atop" lässt sich überprüfen ob deine eigenen Prozesse viel Disk-Aktivität belegen. Wenn nein sollte man den Anbieter wegem dem Problem kontaktieren, du selber kannst das dann nämlich nicht beeinflussen.

Zitat:
Ein Umstieg auf SSD wäre doch recht teuer, und dann hätte ich noch mehr unterbeschäftigte CPU-Kerne
Je nach Resultat deiner Feststellung wäre der Umstieg auf einen anderen Betreiber eventuell sinnvoller.
__________________
Einige Beiträge sind auf meinem Smartphone verfasst. Bitte Tippfehler und Abkürzungen entschuldigen!
Bitte keine ICQ/MSN/Skype Kontaktaufnahmen ohne vorherige persoenliche Absprache.
Mit Zitat antworten
  #3  
Alt 09.01.2018, 15:04
ThomasChr ThomasChr ist offline
Registered User
 
Registriert seit: 08.2014
Beiträge: 343
Ist das zufällig bei Strato oder 1&1?
Dann gehört das so - hatte bei denen schon oft grausame überbuchungen vom Storage erlebt.
__________________
www.thomaschristlieb.de
Mit Zitat antworten
  #4  
Alt 09.01.2018, 18:01
andreas0 andreas0 ist offline
Registered User
 
Registriert seit: 09.2009
Beiträge: 411
Zitat:
Zitat von tomcat8 Beitrag anzeigen
Munin erzählt mir, dass meine Disk Latency im Minimum bei 7ms liegt, im Durchschnitt bei 120ms und das Maximum sind 2,8 Sekunden(!).
Das kommt mir doch etwas viel vor.
Das Ergebnis ist jedenfalls, dass ein eigentlich völlig unterbeschäftigtes System (6 CPU-Kerne, 18GB Speicher; Load liegt bei 0,1) trotzdem gelegentlich unbefriedigende Antwortzeiten liefert :-(

...

Ein Umstieg auf SSD wäre doch recht teuer, und dann hätte ich noch mehr unterbeschäftigte CPU-Kerne :-|
Ich schätze mal, dass man bei so einer Konfiguration, bei der sich eine unbestimmte Anzahl weiterer Kunden ein SSD- oder Festplatten-Array auf einen sehr großen Server teilen, nicht erwarten kann, dass die Datenträgerwartezeit (disk latency) annähernd so gut sein wird, wie bei einem echten dedizierten Server mit recht guten SSD´s / Festplatten oder wie bei einem virtuellen Server, bei dem den Kunden ein exklusives SSD- oder Festplatten-Array, so wie es z.B. derzeit die Provider Hosteurope und Webtropia bei deren Root-Servern dem Kunden anbieten, verlangt werden kann.

Zitat:
Zitat von ThomasChr Beitrag anzeigen
Ist das zufällig bei Strato oder 1&1?
Dann gehört das so - hatte bei denen schon oft grausame überbuchungen vom Storage erlebt.
Aufgrund der 6 CPU-Kerne, 18GB RAM und die Wahl zwischen SAS- und SSD-Platten tippe ich eher mal auf einen Root-Server vom Provider Netcup mit der Typenbezeichnung "RS 3000 SAS G7" für ca. 19 Euro pro Monat.
Mit Zitat antworten
  #5  
Alt 09.01.2018, 19:33
tomcat8 tomcat8 ist offline
Registered User
 
Registriert seit: 05.2017
Beiträge: 10
Zitat:
Zitat von andreas0 Beitrag anzeigen
Ich schätze mal, dass man bei so einer Konfiguration, bei der sich eine unbestimmte Anzahl weiterer Kunden ein SSD- oder Festplatten-Array auf einen sehr großen Server teilen, nicht erwarten kann, dass die Datenträgerwartezeit (disk latency) annähernd so gut sein wird, wie bei einem echten dedizierten Server mit recht guten SSD´s / Festplatten oder wie bei einem virtuellen Server, bei dem den Kunden ein exklusives SSD- oder Festplatten-Array, ..., verlangt werden kann.
Nein, das verlange ich auch nicht.
Darum ja auch meine Frage, was denn so erwartbar ist.
- Im Moment liegen die Latenzen bei meiner Hauptanwendung bei 50ms (Vorgestern waren es noch 60ms) mit etlichen Ausreißern bis zu 500ms.
- Auf meinen lokalen PC mit SSD bei 1ms konstant.
- Dann habe ich hier noch ein billig-uralt-NAS (normale Festplatte), das immerhin bei 15ms liegt.

Hätte ich halbwegs zuverlässige 20-30ms wäre ich damit zufrieden :-)
Mit Zitat antworten
  #6  
Alt 09.01.2018, 23:30
andreas0 andreas0 ist offline
Registered User
 
Registriert seit: 09.2009
Beiträge: 411
Zitat:
Zitat von tomcat8 Beitrag anzeigen
Nein, das verlange ich auch nicht.
Darum ja auch meine Frage, was denn so erwartbar ist.
Richtwerte gibt es da wohl nicht. Aber eventuell reicht es schon aus, was dir das Tool ioping ausgibt. Denn dass zeigt an einigen Stellen an, wann es zu langsam ist.

Wenn du das Tool ioping wie folgt aufrufst, so sieht das Ergebnis wie in folgenden Beispiel aus:

Code:
ioping -c 50 $HOME

4 KiB <<< . (ext4 /dev/sda7): request=1 time=343.6 us (warmup)
4 KiB <<< . (ext4 /dev/sda7): request=2 time=136.3 ms
4 KiB <<< . (ext4 /dev/sda7): request=3 time=369.9 us
4 KiB <<< . (ext4 /dev/sda7): request=4 time=235.3 ms
4 KiB <<< . (ext4 /dev/sda7): request=5 time=164.7 ms
4 KiB <<< . (ext4 /dev/sda7): request=6 time=628.3 us
4 KiB <<< . (ext4 /dev/sda7): request=7 time=50.0 ms
4 KiB <<< . (ext4 /dev/sda7): request=8 time=39.2 ms
4 KiB <<< . (ext4 /dev/sda7): request=9 time=5.25 ms (fast)
4 KiB <<< . (ext4 /dev/sda7): request=10 time=235.8 us (fast)
4 KiB <<< . (ext4 /dev/sda7): request=11 time=12.3 ms
4 KiB <<< . (ext4 /dev/sda7): request=12 time=16.9 ms
4 KiB <<< . (ext4 /dev/sda7): request=13 time=591.6 us (fast)
4 KiB <<< . (ext4 /dev/sda7): request=14 time=6.50 ms (fast)
4 KiB <<< . (ext4 /dev/sda7): request=15 time=17.8 ms
4 KiB <<< . (ext4 /dev/sda7): request=16 time=89.7 ms
4 KiB <<< . (ext4 /dev/sda7): request=17 time=310.3 us (fast)
4 KiB <<< . (ext4 /dev/sda7): request=18 time=15.0 ms
4 KiB <<< . (ext4 /dev/sda7): request=19 time=36.5 ms
4 KiB <<< . (ext4 /dev/sda7): request=20 time=491.5 us (fast)
4 KiB <<< . (ext4 /dev/sda7): request=21 time=20.7 ms
4 KiB <<< . (ext4 /dev/sda7): request=22 time=22.4 ms
4 KiB <<< . (ext4 /dev/sda7): request=23 time=36.4 ms
4 KiB <<< . (ext4 /dev/sda7): request=24 time=32.1 ms
4 KiB <<< . (ext4 /dev/sda7): request=25 time=253.1 us (fast)
4 KiB <<< . (ext4 /dev/sda7): request=26 time=32.2 ms
4 KiB <<< . (ext4 /dev/sda7): request=27 time=170.0 ms
4 KiB <<< . (ext4 /dev/sda7): request=28 time=837.0 ms (slow)
4 KiB <<< . (ext4 /dev/sda7): request=29 time=104.0 ms
4 KiB <<< . (ext4 /dev/sda7): request=30 time=9.60 ms (fast)
4 KiB <<< . (ext4 /dev/sda7): request=31 time=599.4 ms
4 KiB <<< . (ext4 /dev/sda7): request=32 time=259.5 us (fast)
4 KiB <<< . (ext4 /dev/sda7): request=33 time=20.4 ms (fast)
4 KiB <<< . (ext4 /dev/sda7): request=34 time=14.6 ms (fast)
4 KiB <<< . (ext4 /dev/sda7): request=35 time=6.70 ms (fast)
4 KiB <<< . (ext4 /dev/sda7): request=36 time=23.0 ms (fast)
4 KiB <<< . (ext4 /dev/sda7): request=37 time=23.1 ms (fast)
4 KiB <<< . (ext4 /dev/sda7): request=38 time=179.7 ms
4 KiB <<< . (ext4 /dev/sda7): request=39 time=28.4 ms (fast)
4 KiB <<< . (ext4 /dev/sda7): request=40 time=24.5 ms (fast)
4 KiB <<< . (ext4 /dev/sda7): request=41 time=323.3 us (fast)
4 KiB <<< . (ext4 /dev/sda7): request=42 time=14.1 ms (fast)
4 KiB <<< . (ext4 /dev/sda7): request=43 time=20.3 ms (fast)
4 KiB <<< . (ext4 /dev/sda7): request=44 time=20.5 ms (fast)
4 KiB <<< . (ext4 /dev/sda7): request=45 time=8.35 ms (fast)
4 KiB <<< . (ext4 /dev/sda7): request=46 time=22.5 ms (fast)
4 KiB <<< . (ext4 /dev/sda7): request=47 time=14.7 ms (fast)
4 KiB <<< . (ext4 /dev/sda7): request=48 time=16.6 ms (fast)
4 KiB <<< . (ext4 /dev/sda7): request=49 time=650.4 us (fast)
4 KiB <<< . (ext4 /dev/sda7): request=50 time=181.6 ms

--- . (ext4 /dev/sda7) ioping statistics ---
49 requests completed in 3.31 s, 196 KiB read, 14 iops, 59.2 KiB/s
generated 50 requests in 49.2 s, 200 KiB, 1 iops, 4.07 KiB/s
min/avg/max/mdev = 235.8 us / 67.6 ms / 837.0 ms / 147.5 ms
Während dieser IO-Aufzeichnung mit Hilfe des Tools ioping hatte ich auch noch parallel mit Hilfe des DD-Befelhls eine 100 GB große Datei erzeugt, da ansonsten die IO-Werte zu gut ausgesehen hätten.


Zitat:
Zitat von tomcat8 Beitrag anzeigen
- Auf meinen lokalen PC mit SSD bei 1ms konstant.
- Dann habe ich hier noch ein billig-uralt-NAS (normale Festplatte), das immerhin bei 15ms liegt.
Das meinte ich. Du nutzt diese beiden Systeme exklusiv, also ganz alleine für dich. Aber den großen Server teilen sich eine unbestimmte Anzahl an weitere Kunden, so dass es zu solchen Engpässen halt kommen kann. Das reicht schon aus, wenn ein anderer Kunde während deiner Messung nur einfach mit Hilfe des DD-Befehls mal soeben eine 100 GB große Datei erzeugt, um damit die Schreibgeschwindigkeit seiner virtuellen Festplatte zu testen.
Mit Zitat antworten
  #7  
Alt 10.01.2018, 11:38
PHP-Friends PHP-Friends ist offline
verifizierter Anbieter
 
Registriert seit: 08.2014
Ort: Oberhausen
Beiträge: 593
Zitat:
Zitat von andreas0 Beitrag anzeigen
Ich schätze mal, dass man bei so einer Konfiguration, bei der sich eine unbestimmte Anzahl weiterer Kunden ein SSD- oder Festplatten-Array auf einen sehr großen Server teilen, nicht erwarten kann, dass die Datenträgerwartezeit (disk latency) annähernd so gut sein wird, wie bei einem echten dedizierten Server mit recht guten SSD´s / Festplatten
Der Aussage stimme ich teilweise zu. Dedizierte Hardware kann definitiv schneller sein - sie kostet aber sehr viel mehr. Preis-/leistungstechnisch gewinnt im Rahmen "üblicher" Anforderungen ein guter vServer fast immer. Zwar schluckt die Virtualisierung immer etwas Leistung (in dem Kontext fügt sie vor allem Latenz hinzu), das fällt jedoch bei einem entsprechend potent aufgestellten Hostsystem in der Regel nicht ins Gewicht, da ein vergleichbar teurer dedizierter Server höchstwahrscheinlich nicht nur schlechtere Hardware verbaut hat, sondern auch einfach langsamer ist. Für den Preis eines vServers wird man normalerweise noch nicht einmal Datacenter-SSDs erhalten - was nicht heißt, dass die Latenz nicht trotzdem minimal besser sein könnte, aber alle anderen Aspekte sind es mit einiger Sicherheit nicht.

Zitat:
Zitat von andreas0 Beitrag anzeigen
oder wie bei einem virtuellen Server, bei dem den Kunden ein exklusives SSD- oder Festplatten-Array, so wie es z.B. derzeit die Provider Hosteurope und Webtropia bei deren Root-Servern dem Kunden anbieten, verlangt werden kann.
Das kommt natürlich auf den Aufbau des Arrays an. Zwei "eigene" SSDs dürften, auch aufgrund der Virtualisierung, keine besseren IOPS oder Zugriffszeiten bieten als ein großes Array mit 8, 16, 24, ... SSDs. Man kann hier primär Peaks durch andere Kunden verhindern. Unserer Erfahrung nach sind aber gerade auf SSD-Systemen Peaks durch einzelne VMs, die wirklich andere Kunden beeinträchtigen, so selten, dass zumindest wir an dieser Stelle kaum Limitierungen einsetzen müssen.

Falls es jemanden interessiert, ich habe den ioping-Test mal auf einem beliebigen managed Server von uns ausgeführt:

Code:
4 KiB from /dev/vda (block device 50 GiB): request=1 time=306 us
4 KiB from /dev/vda (block device 50 GiB): request=2 time=383 us
4 KiB from /dev/vda (block device 50 GiB): request=3 time=383 us
4 KiB from /dev/vda (block device 50 GiB): request=4 time=321 us
4 KiB from /dev/vda (block device 50 GiB): request=5 time=541 us
4 KiB from /dev/vda (block device 50 GiB): request=6 time=2.63 ms
4 KiB from /dev/vda (block device 50 GiB): request=7 time=353 us
4 KiB from /dev/vda (block device 50 GiB): request=8 time=303 us
4 KiB from /dev/vda (block device 50 GiB): request=9 time=2.16 ms
4 KiB from /dev/vda (block device 50 GiB): request=10 time=298 us
4 KiB from /dev/vda (block device 50 GiB): request=11 time=411 us
4 KiB from /dev/vda (block device 50 GiB): request=12 time=364 us
4 KiB from /dev/vda (block device 50 GiB): request=13 time=347 us
4 KiB from /dev/vda (block device 50 GiB): request=14 time=3.02 ms
4 KiB from /dev/vda (block device 50 GiB): request=15 time=334 us
4 KiB from /dev/vda (block device 50 GiB): request=16 time=432 us
4 KiB from /dev/vda (block device 50 GiB): request=17 time=394 us
4 KiB from /dev/vda (block device 50 GiB): request=18 time=401 us
4 KiB from /dev/vda (block device 50 GiB): request=19 time=496 us
4 KiB from /dev/vda (block device 50 GiB): request=20 time=356 us
4 KiB from /dev/vda (block device 50 GiB): request=21 time=387 us
4 KiB from /dev/vda (block device 50 GiB): request=22 time=858 us
4 KiB from /dev/vda (block device 50 GiB): request=23 time=387 us
4 KiB from /dev/vda (block device 50 GiB): request=24 time=440 us
4 KiB from /dev/vda (block device 50 GiB): request=25 time=361 us
4 KiB from /dev/vda (block device 50 GiB): request=26 time=596 us
4 KiB from /dev/vda (block device 50 GiB): request=27 time=376 us
4 KiB from /dev/vda (block device 50 GiB): request=28 time=356 us
4 KiB from /dev/vda (block device 50 GiB): request=29 time=336 us
4 KiB from /dev/vda (block device 50 GiB): request=30 time=372 us
4 KiB from /dev/vda (block device 50 GiB): request=31 time=292 us
4 KiB from /dev/vda (block device 50 GiB): request=32 time=1.62 ms
4 KiB from /dev/vda (block device 50 GiB): request=33 time=353 us
4 KiB from /dev/vda (block device 50 GiB): request=34 time=442 us
4 KiB from /dev/vda (block device 50 GiB): request=35 time=344 us
4 KiB from /dev/vda (block device 50 GiB): request=36 time=580 us
4 KiB from /dev/vda (block device 50 GiB): request=37 time=436 us
4 KiB from /dev/vda (block device 50 GiB): request=38 time=354 us
4 KiB from /dev/vda (block device 50 GiB): request=39 time=410 us
4 KiB from /dev/vda (block device 50 GiB): request=40 time=409 us
4 KiB from /dev/vda (block device 50 GiB): request=41 time=417 us
4 KiB from /dev/vda (block device 50 GiB): request=42 time=612 us
4 KiB from /dev/vda (block device 50 GiB): request=43 time=414 us
4 KiB from /dev/vda (block device 50 GiB): request=44 time=388 us
4 KiB from /dev/vda (block device 50 GiB): request=45 time=446 us
4 KiB from /dev/vda (block device 50 GiB): request=46 time=295 us
4 KiB from /dev/vda (block device 50 GiB): request=47 time=316 us
4 KiB from /dev/vda (block device 50 GiB): request=48 time=433 us
4 KiB from /dev/vda (block device 50 GiB): request=49 time=581 us
4 KiB from /dev/vda (block device 50 GiB): request=50 time=386 us

--- /dev/vda (block device 50 GiB) ioping statistics ---
50 requests completed in 49.0 s, 1.77 k iops, 6.92 MiB/s
min/avg/max/mdev = 292 us / 564 us / 3.02 ms / 558 us
Das Host-RAID kommt auf 270.5 us (avg).

Viele Grüße
Tim
__________________
PHP-Friends | vollvirtualisierte SSD-Server
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 hi@php-friends.de | Telefon +49 201 857 938 01 | Fax +49 201 857 938 00
Mit Zitat antworten
  #8  
Alt 10.01.2018, 17:33
tomcat8 tomcat8 ist offline
Registered User
 
Registriert seit: 05.2017
Beiträge: 10
Zitat:
Zitat von andreas0 Beitrag anzeigen
Richtwerte gibt es da wohl nicht. Aber eventuell reicht es schon aus, was dir das Tool ioping ausgibt. Denn dass zeigt an einigen Stellen an, wann es zu langsam ist.

Wenn du das Tool ioping wie folgt aufrufst, so sieht das Ergebnis wie in folgenden Beispiel aus:

Code:
ioping -c 50 $HOME
Sieht bei mir so aus:
Code:
4 KiB <<< /root (ext4 /dev/sda3): request=1 time=7.43 ms (warmup)
4 KiB <<< /root (ext4 /dev/sda3): request=2 time=408.1 us
4 KiB <<< /root (ext4 /dev/sda3): request=3 time=400.7 us
4 KiB <<< /root (ext4 /dev/sda3): request=4 time=303.4 us
4 KiB <<< /root (ext4 /dev/sda3): request=5 time=432.2 us
4 KiB <<< /root (ext4 /dev/sda3): request=6 time=429.6 us
4 KiB <<< /root (ext4 /dev/sda3): request=7 time=9.60 ms (slow)
4 KiB <<< /root (ext4 /dev/sda3): request=8 time=9.70 ms (slow)
4 KiB <<< /root (ext4 /dev/sda3): request=9 time=18.2 ms (slow)
4 KiB <<< /root (ext4 /dev/sda3): request=10 time=515.8 us (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=11 time=4.60 ms
4 KiB <<< /root (ext4 /dev/sda3): request=12 time=268.0 us (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=13 time=171.4 ms (slow)
4 KiB <<< /root (ext4 /dev/sda3): request=14 time=1.56 ms (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=15 time=453.6 us (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=16 time=6.94 ms (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=17 time=501.6 us (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=18 time=5.73 ms (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=19 time=1.08 ms (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=20 time=247.7 us (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=21 time=474.1 us (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=22 time=340.1 us (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=23 time=5.79 ms (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=24 time=345.9 us (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=25 time=270.4 us (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=26 time=13.1 ms
4 KiB <<< /root (ext4 /dev/sda3): request=27 time=11.9 ms
4 KiB <<< /root (ext4 /dev/sda3): request=28 time=10.7 ms
4 KiB <<< /root (ext4 /dev/sda3): request=29 time=981.7 ms (slow)
4 KiB <<< /root (ext4 /dev/sda3): request=30 time=145.1 ms
4 KiB <<< /root (ext4 /dev/sda3): request=31 time=39.0 ms (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=32 time=18.9 ms (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=33 time=13.7 ms (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=34 time=861.9 us (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=35 time=26.2 ms (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=36 time=360.0 us (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=37 time=30.6 ms (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=38 time=405.3 us (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=39 time=554.5 us (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=40 time=6.50 ms (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=41 time=81.2 ms
4 KiB <<< /root (ext4 /dev/sda3): request=42 time=388.5 ms
4 KiB <<< /root (ext4 /dev/sda3): request=43 time=369.4 us (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=44 time=11.9 ms (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=45 time=434.5 us (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=46 time=351.3 us (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=47 time=333.5 us (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=48 time=13.3 ms (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=49 time=6.18 ms (fast)
4 KiB <<< /root (ext4 /dev/sda3): request=50 time=319.1 us (fast)

--- /root (ext4 /dev/sda3) ioping statistics ---
49 requests completed in 2.04 s, 196 KiB read, 23 iops, 96.0 KiB/s
generated 50 requests in 49.0 s, 200 KiB, 1 iops, 4.08 KiB/s
min/avg/max/mdev = 247.7 us / 41.7 ms / 981.7 ms / 149.3 ms
981.7 ms: Da sind wieder, diese nervigen Ausreißer;
wenn beim Client 90% der Daten flott angezeigt werden, aber 10% irgendwann hinterhergekleckert kommen, entsteht bei dem Anwender der Eindruck, dass das System irgendwie lahm ist :-(

Wenn ich das ein paarmal wiederhole habe ich extrem streuende Werte:
Code:
min/avg/max/mdev = 300.0 us / 743.8 us / 8.53 ms / 1.26 ms
min/avg/max/mdev = 288.1 us / 1.78 ms / 20.7 ms / 3.63 ms
min/avg/max/mdev = 282.8 us / 565.5 us / 5.85 ms / 896.3 us
Mit Zitat antworten
  #9  
Alt 10.01.2018, 18:10
andreas0 andreas0 ist offline
Registered User
 
Registriert seit: 09.2009
Beiträge: 411
Zitat:
Zitat von tomcat8 Beitrag anzeigen
981.7 ms: Da sind wieder, diese nervigen Ausreißer;
wenn beim Client 90% der Daten flott angezeigt werden, aber 10% irgendwann hinterhergekleckert kommen, entsteht bei dem Anwender der Eindruck, dass das System irgendwie lahm ist :-(

Wenn ich das ein paarmal wiederhole habe ich extrem streuende Werte
Das sieht sehr übel aus und ist auch ein typisches Fehlerbild solcher Konfigurationen, sofern ein weiterer Kunde auf dem gleichen Hostsystem viel IO erzeugen sollte.

Es gibt aber auch noch das Tool iotop, welches nur mit Root-Rechten ausgeführt werden kann, mit dem du so ähnlich wie mit dem Tool TOP herausfinden kannst, welcher Prozeß am meisten IO auf deinem vServer erzeugt.

Nachdem du damit herausgefunden hast, welcher Prozeß an erster Stelle von diesem Tool angezeigt wird, würde ich mal testweise gerade diesen Prozeß, der eventuell der Übeltäter sein könnte, einfach mal testweise beenden und danach die Messung mit dem Tool ioping wiederholen. Eventuell auch öfters wiederholen.

Eventuell hast du Glück und es lag bzw. liegt nur an dem testweise beendeten Prozeß auf deinem vServer, der eventuell zurzeit nur unkontrolliert läuft bzw. lief und dadurch sehr viel unerwünschtes IO zusätzlich erzeugt bzw. erzeugt hatte.

Geändert von andreas0 (10.01.2018 um 18:24 Uhr) Grund: Text korrigiert.
Mit Zitat antworten
  #10  
Alt 11.01.2018, 19:36
tomcat8 tomcat8 ist offline
Registered User
 
Registriert seit: 05.2017
Beiträge: 10
Das System ist noch langsamer geworden :-(
Meine wichtigste Anwendung benötigt jetzt durchschnittlich 75ms, um 20k von der Platze zu kratzen.
Da verliere ich die Geduld.
Hier ein Auszug aus meinen Log-Files:
Code:
(Timestamp -- ThreadId -- [#Bytes] [#ms])
11 Jan 2018 18:10:02,728 -- 4 --  [19479]  [66] 
11 Jan 2018 18:10:02,742 -- 5 --  [20671]  [1] 
11 Jan 2018 18:10:02,743 -- 15 -- [19846]  [81] 
11 Jan 2018 18:10:02,756 -- 16 -- [20772]  [10] 
11 Jan 2018 18:10:02,767 -- 9 --  [16422]  [16] 
? fast 10 Sekunden Pause ?
11 Jan 2018 18:10:12,074 -- 6 --  [17558]  [1033] 
11 Jan 2018 18:10:12,078 -- 5 --  [19453]  [1013] 
11 Jan 2018 18:10:12,160 -- 4 --  [21195]  [1095] 
11 Jan 2018 18:10:12,160 -- 17 -- [19022]  [1119] 
11 Jan 2018 18:10:12,255 -- 3 --  [18327]  [1214] 
11 Jan 2018 18:10:12,255 -- 12 -- [15858]  [1214] 
11 Jan 2018 18:10:12,261 -- 16 -- [17879]  [6] 
11 Jan 2018 18:10:12,265 -- 15 -- [14546]  [101] 
11 Jan 2018 18:10:12,295 -- 9 --  [19760]  [28]
Die Antwortzeiten im Vergleich hier nochmal zum mitrechnen:
- 1ms: PC mit SSD
- 16ms: Uralt-billig NAS mit HDD (1Gbit)
- 60ms: Raspberry Pi(!!) als "Fileserver" (100Mbit, SD-Card!!)
- 75ms: VServer (schwankend zwischen 1 und 1200ms)
Das heißt nicht anderes, dass das Teil bezüglich Disk-IO langsamer ist als ein Raspberry Pi!
Bisher war ich der Meinung, dass ein VServer das bessere Konzept ist, aber jetzt habe ich große Zweifel;
das Zauberwort lautet "Quality Of Service"; und da ist der Raspberry Pi sogar besser:
Ich kann mich darauf verlassen, in 60ms ein Ergebnis zu haben, während der Vserver in seinem Antwortverhalten um den Faktor 1000 schwankt, und zudem gelegentlich ausgiebige Kaffeepausen einlegt :-(

Ich werde wohl auf einen dedicated umsteigen, auch wenn er das doppelte kostet.
Mit Zitat antworten
  #11  
Alt 11.01.2018, 20:04
Benutzerbild von d4f
d4f d4f ist offline
Support Guru
 
Registriert seit: 04.2007
Ort: /dev/urandom
Beiträge: 4.309
d4f eine Nachricht über ICQ schicken d4f eine Nachricht über MSN schicken
Zitat:
Ich werde wohl auf einen dedicated umsteigen, auch wenn er das doppelte kostet.
Offensichtlich ist wohl eher der Provider untauglich, schlecht oder inkompetent - oder eine Kombination dieser Faktoren.
Ich würde dringend einen besseren Anbieter empfehlen, bspw Php-Friends hat sich ja schon hier im Thread beteiligt.
Mit Zitat antworten
  #12  
Alt 11.01.2018, 20:29
andreas0 andreas0 ist offline
Registered User
 
Registriert seit: 09.2009
Beiträge: 411
Zitat:
Zitat von tomcat8 Beitrag anzeigen
Bisher war ich der Meinung, dass ein VServer das bessere Konzept ist, aber jetzt habe ich große Zweifel;
Wenn die Provider aufgrund des hohen Preisdrucks ihre Hostsysteme nicht überbuchen würden, dann wäre es auch tatsächlich so.
Da die virtuellen Server z.B. von PHP-Friends nicht gerade zu den billigsten Servern gehören, zumal deren Laufwerke aus meiner Sicht extrem klein sind, könntest du eventuell bei diesem Provider mehr Glück haben, was das IO-Verhalten angeht.


Zitat:
Zitat von tomcat8 Beitrag anzeigen
Ich werde wohl auf einen dedicated umsteigen, auch wenn er das doppelte kostet.
Gute Erfahrungen habe ich bisher mit echten dedizierten Servern mit zusätzlichem Hardware-RAID-Controller gemacht. Von daher schau auch aufgrund des besseren IO-Verhaltens nach einem Server mit Hardware-RAID-Controller. RAID 1 reicht dafür aus meiner Sicht schon völlig aus.
Mit Zitat antworten
  #13  
Alt 11.01.2018, 20:39
tomcat8 tomcat8 ist offline
Registered User
 
Registriert seit: 05.2017
Beiträge: 10
Zitat:
Zitat von d4f Beitrag anzeigen
Php-Friends hat sich ja schon hier im Thread beteiligt.
... aber deren System kommen für mich nicht in Frage, weil ich erheblich mehr Diskspace benötige!
Ich habe jetzt 320GB belegt, von denen allein 120GB für die "schnelle" Anwendung per SSD vorgesehen sind.
Die größte Disk hat bei php-Friends 200GB; damit kann ich nix anfangen, und dann ist das System auch noch teurer als ein Dedi!
Mein Wunschsystem:
- 2-4 CPU-Kerne; > 2 GHz
- 16 GB Hauptspeicher
- 200 GB SSD
- 500 GB HDD
- Debian 9 (haben php-Friends auch nicht!)

Markt! Wo bist du, wenn man dich braucht?
Mit Zitat antworten
  #14  
Alt 11.01.2018, 21:20
andreas0 andreas0 ist offline
Registered User
 
Registriert seit: 09.2009
Beiträge: 411
Zitat:
Zitat von tomcat8 Beitrag anzeigen
Markt! Wo bist du, wenn man dich braucht?
Wenn dir ein echter dedizierter Server mit zusätzlichem RAID-Controller zu teuer sein sollte, so schau dir auch mal den virtuellen Server mit der Produktbezeichnung "VPS XL SSD" des Providers Contabo näher an. Denn aufgrund der doch sehr großen virtuellen Festplatte von 1,2 TB nutze ich soeinen als virtuellen Datenspeicher, dessen technische Daten wie folgt aussehen:

Produktbezeichnung: VPS XL SSD
vCores: 10
Prozessortyp: Intel Xeon E5-2620v3, E5-2630v4 oder 4114 Prozessor
RAM: 50 GB (angeblich garantiert)
Festplatte: 1200 GB Speicherplatz (angeblich 100% SSD)
Derzeitiger Preis: 27 Euro (aufgerundet) pro Monat

Das Meßergebnis sieht derzeit auf diesem vServer wie folgt aus:

Code:
ioping -c 50 -A -D $HOME
--- . (ext4 /dev/sda7) ioping statistics ---
49 requests completed in 12.8 ms, 196 KiB read, 3.83 k iops, 15.0 MiB/s
generated 50 requests in 49.0 s, 200 KiB, 1 iops, 4.08 KiB/s
min/avg/max/mdev = 164.2 us / 261.0 us / 432.5 us / 60.6 us
Das Ergebnis ist vor allem immer recht gleichmäßig.
Mit Zitat antworten
  #15  
Alt 11.01.2018, 21:56
PHP-Friends PHP-Friends ist offline
verifizierter Anbieter
 
Registriert seit: 08.2014
Ort: Oberhausen
Beiträge: 593
Guten Abend,

Zitat:
Zitat von andreas0 Beitrag anzeigen
Da die virtuellen Server z.B. von PHP-Friends nicht gerade zu den billigsten Servern gehören [..] könntest du eventuell bei diesem Provider mehr Glück haben, was das IO-Verhalten angeht.
Siehe oben - ich habe bereits ein (echtes ) Testergebnis von einem (beliebigen) unserer managed Server gepostet. Diese Leistung kann summa summarum von jedem unserer vServer erwartet werden, da gibt es keine großen Differenzen in der Auslastung sowie Ausstattung der Nodes.

Zitat:
Zitat von andreas0 Beitrag anzeigen
zumal deren Laufwerke aus meiner Sicht extrem klein sind
Das mag, verglichen mit einigen Angeboten auf dem Markt, durchaus stimmen. Hier spielen verschiedene Faktoren eine Rolle. Zunächst einmal sehen wir, dass in den meisten Fällen der Bedarf an großem SSD-Speicher nicht gegeben ist, also ein Kunde mit SSDs primär auf die Leistung und nicht auf das Speichern großer Datenmengen aus ist. Für einen Kompromiss zwischen Leistung und Performance eignet sich ein "dickes" RAID-10 aus beispielsweise 16 SAS-Platten besser (bezogen auf ein ganzes Hostsystem). Das kann man natürlich nicht grundsätzlich verallgemeinern, ist aber in den meisten Fällen so. Das sehen wir beispielsweise auch an der Belegung unserer managed Server. Diese beläuft sich im Schnitt auf unter 50%, trotzdessen unsere SSDs so klein sind.

Technisch und kaufmännisch gibt es zwei wesentliche Aspekte für unsere Angebotsgestaltung:

1) Wir verwenden ausschließlich echte Datacenter-SSDs von Samsung. Diese sind nun mal deutlich teurer als Desktop-SSDs. Das gleiche gilt für die Gehäuse, die notwendig sind, um diese SSD-Mengen unterzubringen. Ein Tower ist natürlich erheblich billiger. Schlussendlich schluckt das RAID-10 auch noch den halben Bruttospeicher, ist dafür aber wirklich schnell, sehr sicher und extrem flott im Rebuild.

2) Jeder Kunde erhält ein "echtes" Logical Volume auf dem Host. Speicher, den wir verkaufen, ist wirklich weg. Da gibt es nichts, was man overcommitten und somit mischkalkulieren könnte. Nun mag man sich zu Recht fragen, ob das nicht einen der Virtualisierungsvorteile zunichte macht, was bezogen darauf, den besten Preis aus der Hardware herauszuholen, auch stimmt. Aber in Sachen Performance und Sicherheit (genau genommen: Datenverfügbarkeit) verhalten sich Logical Volumes besser als QCOW-Dateien. Die Leistung entspricht quasi der nativen Performance einer echten Partition, da hier (ja, etwas ungenau formuliert) "nur" physikalische Speicherbereiche über den Linux-Device-Mapper alloziert werden. Sicherer ist dies, weil Schäden am Host-Dateisystem für die VMs völlig egal sind. Und so sehr muss es gar nicht knallen, um eine QCOW-Datei de facto zu zerstören.

Einige Mitbewerber verwenden ggf. keine echten Logical Volumes, keine Datacenter-SSDs, kein RAID-10 oder - ja, auch schon gesehen - einfach gar keine SSDs, obwohl SSD dran steht (was ich selbstverständlich keinem seriösen Mitbewerber mit guten Preisen unterstellen möchte).

Zitat:
Zitat von tomcat8 Beitrag anzeigen
Die größte Disk hat bei php-Friends 200GB; damit kann ich nix anfangen
Können wir upgraden (https://php-friends.de/hilfe), wird dann aber leider auch teurer.

Zitat:
Zitat von tomcat8 Beitrag anzeigen
und dann ist das System auch noch teurer als ein Dedi!
Wenn es um viel SSD-Speicher geht und andere Aspekte wie RAID-10 oder richtige Serverhardware (im Rack) zu vernachlässigen sind, kann ein dedizierter Server besser geeignet sein. Dieser wird aber qualitativ nicht das gleiche bieten können wie ein guter vServer. Dafür lege ich meine Hand ins Feuer.

Zitat:
Zitat von tomcat8 Beitrag anzeigen
Debian 9 (haben php-Friends auch nicht!)
Haben wir. Aber danke für den Hinweis, wir müssen die Produktinformationen dahingehend updaten.


Viele Grüße
Tim
__________________
PHP-Friends | vollvirtualisierte SSD-Server
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 hi@php-friends.de | Telefon +49 201 857 938 01 | Fax +49 201 857 938 00
Mit Zitat antworten
Antwort

Lesezeichen



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
Server fährt sich nach 30 Tagen fest peeeti Dedizierte Server 10 25.01.2013 15:33
Postfix zu langsam topoh Mail 96 26.08.2012 11:29
erhöhte Disk Latency mojodoll Dedizierte Server 1 23.07.2011 19:44
Deb Lenny -> Kein Update mehr möglich ( Disk quota exceeded ) HxD Virtuelle Server 12 07.11.2009 17:19
Festplatte voll?? V40 Virtuelle Server 14 28.05.2006 11:09


Welche Disk Latency ist denn so akzeptabel?
Welche Disk Latency ist denn so akzeptabel?
Welche Disk Latency ist denn so akzeptabel? Welche Disk Latency ist denn so akzeptabel?
Powered by vBulletin® Version 3.8.11 (Deutsch)
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2018 DragonByte Technologies Ltd.