Welche Disk Latency ist denn so akzeptabel?

[tomcat8]

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

 

[d4f]

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.

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.

 

[ThomasChr]

Ist das zufällig bei Strato oder 1&1?
Dann gehört das so - hatte bei denen schon oft grausame überbuchungen vom Storage erlebt.

 

[andreas0]

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.

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.

 

[tomcat8]

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

 

[andreas0]

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:

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
[B]4 KiB <<< . (ext4 /dev/sda7): request=28 time=837.0 ms (slow)[/B]
4 KiB <<< . (ext4 /dev/sda7): request=29 time=104.0 ms
4 KiB <<< . (ext4 /dev/sda7): request=30 time=9.60 ms (fast)
[B]4 KiB <<< . (ext4 /dev/sda7): request=31 time=599.4 ms[/B]
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.

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

 

[PHP-Friends]

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.

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:

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

 

[tomcat8]

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:

ioping -c 50 $HOME

Sieht bei mir so aus:

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:

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

 

[andreas0]

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.

 

[tomcat8]

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:

(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.

 

[d4f]

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.

 

[andreas0]

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.

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.

 

[tomcat8]

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?

 

[andreas0]

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:

ioping -c 50 -A -D $HOME
--- . (ext4 /dev/sda7) ioping statistics ---
49 requests completed in 12.8 ms, 196 KiB read, [B]3.83 k iops, 15.0 MiB/s[/B]
generated 50 requests in 49.0 s, 200 KiB, 1 iops, 4.08 KiB/s
min/avg/[B]max[/B]/mdev = 164.2 us / 261.0 us / [B]432.5 us[/B] / 60.6 us

Das Ergebnis ist vor allem immer recht gleichmäßig.

 

[PHP-Friends]

Guten Abend,

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.

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).

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.

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.

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

 

[tomcat8]

Huch, da kommt ja Leben in die Diskussion

Jetzt habe ich vier Optionen:
- Ich habe den Support meines Providers angeschrieben, ob der die angezogene Handbremse doch noch findet...
- Contabo hatte ich mal von meiner Liste gestrichen, habe aber den dafür Grund vergessen :-(
Die Preise sind geradezu unglaublich.
- Dass man bei PHP-Friends optional Diskspace dazukaufen kann, hatte ich nicht gesehen; dann würde aber ein System mit 200GB SSD und 300 GB HDD €43 kosten...
- Bei Webtropia habe ich einen dedicated Server im Auge mit 240GB SSD, 1TB HDD für €40.

Hm, mal abwarten, was mein Provider so sagt...

Nochmal zur Verdeutlichung:
Das ist ein Hobby-Projekt; das darf auch mal ausfallen; alle Daten sind read-only und können mit überschaubarem Aufwand rekonstruiert werden; ich brauche also noch nichtmal Backup.

 

[andreas0]

- Ich habe den Support meines Providers angeschrieben, ob der die angezogene Handbremse doch noch findet...

Bei solchen Providern habe ich leider bisher die Erfahrung sammeln müssen, dass nach so einer Anfrage einfach mein virtueller Server vom Provider nur auf ein anderes Wirtsystem verschoben wurde und nach ca. 1 bis 3 Monaten dann das Problem sich wiederholte.

- Bei Webtropia habe ich einen dedicated Server im Auge mit 240GB SSD, 1TB HDD für €40.

Meinst du einen dedicated Server mit 1 x 240GB SSD und 1 x 1TB HDD für 40 Euro?

- Dass man bei PHP-Friends optional Diskspace dazukaufen kann, hatte ich nicht gesehen; dann würde aber ein System mit 200GB SSD und 300 GB HDD €43 kosten...

Zwar kann man als Kunde nicht sehen, welche Hardware tatsächlich auf dem Wirtsystem verbaut ist. Aber diese darin verbaute Hardware dürfte auf jeden Fall besser sein als die im dedizierten Server vom Provider Webtropia für 40 Euro. Von daher würde in diesem Fall, weil der Preisunterschied nicht wirklich groß ist, dann doch eher zum Angebot vom Provider PHP-Friends raten. Denn wenn auf dem Wirtsystem mal eine der Platten ausfallen sollte, mußt du nur noch aktiv werden, wenn das IO plötzlich nicht mehr stimmen sollte.

 

[d4f]

Bei Webtropia habe ich einen dedicated Server im Auge mit 240GB SSD, 1TB HDD für €40.

Wenn es ein dedizierter Server sein soll würde ich eher zu Hetzner greifen als zu Webtropia. Leicht teurer und leider eine nicht vernachlässigbare Setup-Gebühr aber dafür technisch sehr ausgereift.

Hier sei allerdings die Frage gestellt ob du wirklich aktuell soviel Speicherplatz benötigst oder nur zukunftssicher planen willst. Bei VPS kleinerer Anbieter kann man in aller Regel den Speicher oder das Produkt mit nur einem Reboot oder sogar im laufenden Betrieb vergrössern lassen sobald Bedarf besteht.

 

[tomcat8]

Bei solchen Providern habe ich leider bisher die Erfahrung sammeln müssen, dass nach so einer Anfrage einfach mein virtueller Server vom Provider nur auf ein anderes Wirtsystem verschoben wurde und nach ca. 1 bis 3 Monaten dann das Problem sich wiederholte.

Du bist ein Hellseher; aber es kommt noch besser:
Jetzt hat man mich tatsächlich auf einen anderen Node geschoben, aber da sind die Antwortzeiten noch schlimmer: z.Z. 115ms.
Das ist das doppelte eines Raspberry Pi :-(

Meinst du einen dedicated Server mit 1 x 240GB SSD und 1 x 1TB HDD für 40 Euro?

Ja, habe ich jetzt bestellt.

 

[andreas0]

... aber da sind die Antwortzeiten noch schlimmer: z.Z. 115ms.
Das ist das doppelte eines Raspberry Pi :-(

Auch wenn du jetzt deinen zukünftigen dedicated Server nur mit 1 x 240GB SSD und 1 x 1TB HDD für 40 Euro pro Monat bestellt hast, so denke ich mal, wirst du mit diesem, wenn die Verfügbarkeit für dich eher eine untergeordnete Rolle spielt, bezüglich der kompletten Performance dieses Servers langfristig glücklicher sein. Denn dieser Server wird für deinen Raspberry Pi zur echten Konkurrenz, da du in Zukunft wahrscheinlich dann eher sagen wirst: "Das sind ja nur Antwortzeiten von 1/100 oder gar 1/1000 eines Raspberry Pi´s ".

Wenn du möchtest, kannst du ja mal über den krassen Unterschied zwischen dem jetzt bestellten dedicated Server und dem jetzigen vServer berichten.