Regelmäßige IO Probleme

Ein Ding, das mir auch bei SSDs aufgefallen ist: wenn diese sehr große Datentransfers zu bewältigen haben, ist häufig der DRAM oder SLC Cache irgendwann erschöpft und die hohe Performance bricht deutlich ein. Vielleicht sehen wir das hier ständig.

Muss das Thema wieder hochholen: aktuell ist es imho wieder recht schlimm mit 100% SSD Auslastung bei 5-15 Mbytes/s...

Hatte ich mit einem RS 1000 G9.5 auch, war dann zwischendurch mal woanders, der neue RS 1000 G9.5. OST2023 hat das Problem zum Glück bisher nich.

Mich plagt es auch, Support sagt leider sinngemäß „das ist kein Grund die VM auf einen anderen Host zu verschieben“. Muss da erst was brennen? Was ist denn ein guter Grund die VM zu verschieben?

Zitat von sla

Mich plagt es auch, Support sagt leider sinngemäß „das ist kein Grund die VM auf einen anderen Host zu verschieben“. Muss da erst was brennen? Was ist denn ein guter Grund die VM zu verschieben?

Wobei das vermutlich auch nur eine temporäre Lösung ist, bis auch der neue Node entsprechend viele VMs hat und sich die IO Performance auch dort wieder verschlechtert. Das klingt ja alles eher nicht nach Hardware Problemen, sondern schlicht nach Überprovisionierung. Ich würde in diesem Fall einfach mal die iowait über einen längeren Zeitraum messen und falls die entsprechend hoch ist, damit zum Support gehen. Gerade wenn es ein RS ist. Bei VPS Servern hat man wohl einfach Pech gehabt. Wobei mich das auch nicht wundert, wenn hier alle den ganzen Tag über Yabs Benchmarks laufen lassen

Habe zwei RS, einmal wurde der problematische mit Screenshot als Beweis mit 0-5 Mbytes/s bei 100% Auslastung schon verschoben.

Zitat von sla

Mich plagt es auch, Support sagt leider sinngemäß „das ist kein Grund die VM auf einen anderen Host zu verschieben“. Muss da erst was brennen? Was ist denn ein guter Grund die VM zu verschieben?

Zitat von Paul

Wobei das vermutlich auch nur eine temporäre Lösung ist, bis auch der neue Node entsprechend viele VMs hat und sich die IO Performance auch dort wieder verschlechtert. Das klingt ja alles eher nicht nach Hardware Problemen, sondern schlicht nach Überprovisionierung. Ich würde in diesem Fall einfach mal die iowait über einen längeren Zeitraum messen und falls die entsprechend hoch ist, damit zum Support gehen. Gerade wenn es ein RS ist. Bei VPS Servern hat man wohl einfach Pech gehabt. Wobei mich das auch nicht wundert, wenn hier alle den ganzen Tag über Yabs Benchmarks laufen lassen

Auch aus meiner Sicht wird ein Umzug mittlerweile nicht wirklich helfen. Denn schaut man sich folgendes Ergebnis genauer an, so rieht es eher danach aus, als werden mittlerweile aus Kostengründen die virtuellen Platten der virtuellen Server, egal ob VPS oder RS, auf sogenannte "Block Storage Volumes" ausgelagert. Mehr siehe folgendes Meßergebnis, welches ich auf einen RS 4000 G9.5 erstellt habe:

time fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=8G --readwrite=randrw
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.33
Starting 1 process
test: Laying out IO file (1 file / 8192MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=24.8MiB/s,w=24.9MiB/s][r=6358,w=6371 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=2374819: Thu Oct 19 17:50:34 2023
read: IOPS=7497, BW=29.3MiB/s (30.7MB/s)(4098MiB/139949msec)
bw (  KiB/s): min=28360, max=35544, per=100.00%, avg=30048.32, stdev=390.89, samples=279
iops        : min= 7090, max= 8886, avg=7512.08, stdev=97.72, samples=279
write: IOPS=7488, BW=29.2MiB/s (30.7MB/s)(4094MiB/139949msec); 0 zone resets
bw (  KiB/s): min=28048, max=35784, per=100.00%, avg=30010.55, stdev=759.36, samples=279
iops        : min= 7012, max= 8946, avg=7502.64, stdev=189.84, samples=279
cpu          : usr=3.28%, sys=30.90%, ctx=1342502, majf=0, minf=8
IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued rwts: total=1049199,1047953,0,0 short=0,0,0,0 dropped=0,0,0,0
latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
READ: bw=29.3MiB/s (30.7MB/s), 29.3MiB/s-29.3MiB/s (30.7MB/s-30.7MB/s), io=4098MiB (4298MB), run=139949-139949msec
WRITE: bw=29.2MiB/s (30.7MB/s), 29.2MiB/s-29.2MiB/s (30.7MB/s-30.7MB/s), io=4094MiB (4292MB), run=139949-139949msec

Disk stats (read/write):
vda: ios=1049199/1047997, merge=0/27, ticks=5011124/3871264, in_queue=8883658, util=100.00%

real    2m52,181s
user    0m7,207s
sys     0m54,369s

...und jetzt grade gehts mal wieder... Ich versteh halt das Muster nicht.

Zitat von andreas.

Auch aus meiner Sicht wird ein Umzug mittlerweile nicht wirklich helfen. Denn schaut man sich folgendes Ergebnis genauer an, so rieht es eher danach aus, als werden mittlerweile aus Kostengründen die virtuellen Platten der virtuellen Server, egal ob VPS oder RS, auf sogenannte "Block Storage Volumes" ausgelagert. Mehr siehe folgendes Meßergebnis, welches ich auf einen RS 4000 G9.5 erstellt habe:

Habe ich gerade auch mal ausgeführt:

 time fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=8G --readwrite=randrw
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.35
Starting 1 process
test: Laying out IO file (1 file / 8192MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=7819KiB/s,w=7875KiB/s][r=1954,w=1968 IOPS][eta 00m:00s] 
test: (groupid=0, jobs=1): err= 0: pid=2910712: Thu Oct 19 20:53:19 2023
  read: IOPS=8703, BW=34.0MiB/s (35.7MB/s)(4098MiB/120546msec)
   bw (  KiB/s): min=  880, max=112432, per=100.00%, avg=34907.31, stdev=13562.80, samples=240
   iops        : min=  220, max=28108, avg=8726.83, stdev=3390.70, samples=240
  write: IOPS=8693, BW=34.0MiB/s (35.6MB/s)(4094MiB/120546msec); 0 zone resets
   bw (  KiB/s): min=  824, max=109568, per=100.00%, avg=34866.91, stdev=13447.36, samples=240
   iops        : min=  206, max=27392, avg=8716.73, stdev=3361.84, samples=240
  cpu          : usr=4.63%, sys=22.98%, ctx=1069407, majf=2, minf=10
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=1049199,1047953,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=34.0MiB/s (35.7MB/s), 34.0MiB/s-34.0MiB/s (35.7MB/s-35.7MB/s), io=4098MiB (4298MB), run=120546-120546msec
  WRITE: bw=34.0MiB/s (35.6MB/s), 34.0MiB/s-34.0MiB/s (35.6MB/s-35.6MB/s), io=4094MiB (4292MB), run=120546-120546msec

Disk stats (read/write):
  sda: ios=1050099/1050854, merge=0/44, ticks=6735232/905732, in_queue=7641603, util=99.39%
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test    7.14s user 35.24s system 31% cpu 2:12.46 total

Zitat von sla

Was ist denn ein guter Grund die VM zu verschieben?

Rückläufige Gewinne.

Zitat von andreas.

Denn schaut man sich folgendes Ergebnis genauer an, so rieht es eher danach aus, als werden mittlerweile aus Kostengründen die virtuellen Platten der virtuellen Server, egal ob VPS oder RS, auf sogenannte "Block Storage Volumes" ausgelagert.

Ist das nicht eher sogar ein tolles Feature im Allgemeinen? Bisher ist es ja so, dass wenn der Host abraucht, zwangsläufig auch die Daten verloren sind, wenn die "Platten" in Mitleidenschaft gezogen worden sind. Dann könnte ich endlich an einigen Stellen Redundanz aufgeben da der Storagespace ja nicht für dauerhafte Nutzung geeignet ist.

Zitat von andreas.

Auch aus meiner Sicht wird ein Umzug mittlerweile nicht wirklich helfen. Denn schaut man sich folgendes Ergebnis genauer an, so rieht es eher danach aus, als werden mittlerweile aus Kostengründen die virtuellen Platten der virtuellen Server, egal ob VPS oder RS, auf sogenannte "Block Storage Volumes" ausgelagert. Mehr siehe folgendes Meßergebnis, welches ich auf einen RS 4000 G9.5 erstellt habe:

Meinst du damit, der Storage läuft auf irgendwelchen SAN mit entsprechenden Caching welches dann die Grätsche macht?

Hallo zusammen,

danke für euer Feedback bezüglich der I/O-Performance. Uns sind aktuell hier keine größeren, allgemeinen Probleme bekannt. Wir möchten euren Berichten daher auf jeden Fall detailliert nachgehen, um nachvollziehen zu können, wodurch dies in euren Fällen bedingt ist.

Bitte lasst daher unserem Support via Kontaktformular oder direkt an mail@netcup.de folgende Informationen zukommen:

• Name des Servers
• Tritt das Problem sporadisch auf (gibt es z.B. immer wieder kurze "Hänger") oder ist die Performance dauerhaft schlecht?
• Falls das Problem sporadisch auftritt: Zu welchen Zeiten könnt ihr dies beobachten? Gibt es bestimmte Zeiten, zu denen es besonders schlimm ist?
• Ausgaben von I/O-Speedtests / anderen geeigneten Nachweisen des Problems, falls leicht erstellbar (z.B. wenn das Problem dauerhaft besteht), idealerweise im Rettungssystem erstellt.

Dies ermöglicht es uns, Korrelationen zwischen den betroffenen Servern herzustellen und die Situation schnellstmöglich zu verbessern.

Bitte weist in eurer Nachricht an den Support auf meinen Beitrag hier hin, damit dieser weiß, dass er es direkt an die zuständige Abteilung weiterleiten kann.

Zitat von andreas.

Denn schaut man sich folgendes Ergebnis genauer an, so rieht es eher danach aus, als werden mittlerweile aus Kostengründen die virtuellen Platten der virtuellen Server, egal ob VPS oder RS, auf sogenannte "Block Storage Volumes" ausgelagert.

Um eine höchstmögliche Performance für unsere Kunden sicherzustellen, werden alle Server-Images lokal auf dem Hostsystem gespeichert. Wir verwenden dafür keine Netzwerkspeicher-Systeme.

Vielen Dank für eure Unterstützung!

Bei mir äußert sich das in hohem iowait, ein nano-Editor benötigt sporadisch Sekunden, um zu öffnen. Ein Ticket dazu habe ich vor ca. einem halben Jahr geöffnet, 80.000 Zeilen Log waren wohl nicht ausreichend und es wurde unbearbeitet geschlossen.

Zitat von [netcup] Lars S.

• Ausgaben von I/O-Speedtests / anderen geeigneten Nachweisen des Problems, falls leicht erstellbar (z.B. wenn das Problem dauerhaft besteht), idealerweise im Rettungssystem erstellt.

Vielleicht wäre es dafür von Vorteil, wenn ihr das Rettungssystem mal aktualisiert. Momentan basiert es auf Debian oldoldoldoldstable, sodass man keinerlei Tools wie bspw. hdparm nachinstallieren kann.

Zitat von bjo

Vielleicht wäre es dafür von Vorteil, wenn ihr das Rettungssystem mal aktualisiert. Momentan basiert es auf Debian oldoldoldoldstable, sodass man keinerlei Tools wie bspw. hdparm nachinstallieren kann.

Hallo bjo,

danke für dein Feedback.

Ich habe es an das zuständige Team weitergegeben und darum gebeten, das zu prüfen. Das genannte Tool hdparm ist (neben anderen nützlichen Tools für Tests dieser Art, wie z.B. fio) bereits standardmäßig im Rettungssystem enthalten. Ich kann den Wunsch nach neueren und aktuellen Versionen, sowie der Möglichkeit, ohne Umwege Pakete zu installieren, aber natürlich gut nachvollziehen.

Zitat von [netcup] Lars S.

Hallo bjo,

danke für dein Feedback.

Ich habe es an das zuständige Team weitergegeben und darum gebeten, das zu prüfen. Das genannte Tool hdparm ist (neben anderen nützlichen Tools für Tests dieser Art, wie z.B. fio) bereits standardmäßig im Rettungssystem enthalten. Ich kann den Wunsch nach neueren und aktuellen Versionen, sowie der Möglichkeit, ohne Umwege Pakete zu installieren, aber natürlich gut nachvollziehen.

Wegen eines Durchsatzproblems wurde ich mal vom Support gebeten, iperf3 vom Rettungssystem auszuführen - das ist jedoch nicht im Rettungssystem vorhanden und ließ sich aus og. Gründen auch nicht nachinstallieren.

Zitat von kite

Danke für diese Infos hier. Ich habe seit Monaten genau dieses Problem: mein Server steht jeden Tag mehrmals für 30-60 Sekunden nahezu still, obwohl sich da nur ein paar Container langweilen. Ein uptime zeigt in diesen Momenten regelmäßig ein Load von mindestens Zweistellig an.

Habe schon an mir selbst gezweifelt.

Das Problem besteht seit meinem damaligen Post (Mai) immer noch, aber es es viiiiel seltener geworden (Laut Monitoring und einem einfachen shell-Skript in tmux)

#!/bin/sh

# get load average from /proc/loadavg  (1. value = 1 min avr)
# write to std and file if load >= threshold

threshold=4

while ( true ); do
    myload=$(cat /proc/loadavg)
    myload1=${myload%%.*}
    if [ $myload1 -ge $threshold ]; then
        mydate=$(date)
        echo -n "$mydate -> " | tee -a netcup-checker.log
        echo "$myload -> LOAD: $myload1 <-" | tee -a netcup-checker.log
    fi

    sleep 10
done

Da ich häufig per ssh auf der Maschine bin, fällt es mir auch immer mal wieder auf: Diese Hänger sind mindestens 10-30 Sekunden lang, und fühlen sich wie totaler Stillstand an. Ich habe auch schon mit iostat, iotop und vmstat innerhalb der Schleife gespielt; das war alles komplett unauffällig.

Ich habe mal ein Logfile von Anfang September bis heute an den Support geschickt und hoffe sehr auf eine Lösung

Danke kite, wir werden uns das in den kommenden Wochen auch nochmal anschauen und unsere Ergebnisse hier und mit dem Support teilen, da kommt uns dein Skript sehr gelegen.

Danke auch an [netcup] Lars S. und dem Rest von Netcup, dass ihr euch dem Thema annehmt.

Ticket aufgegeben, IO-Wait von 100 % mit 200 kB_read/s bei einem `git grep` in /etc.