Poor disk performance on RS 16000 G12

cysiek

So i performed same fio as davorzec on my RS 2000 (iddling)

Code

fio --name=mixed_workload --filename=~/fio_test.file --size=10G \
--rw=randrw --rwmixread=75 --bs=4k --ioengine=libaio --direct=1 \
--numjobs=4 --iodepth=16 --runtime=60 --time_based --group_reporting
mixed_workload: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=16
...
fio-3.39
Starting 4 processes
mixed_workload: Laying out IO file (1 file / 10240MiB)
Jobs: 4 (f=0): [f(4)][100.0%][r=284MiB/s,w=93.6MiB/s][r=72.7k,w=23.9k IOPS][eta 00m:00s]
mixed_workload: (groupid=0, jobs=4): err= 0: pid=500344: Mon Aug  3 21:52:35 2026
 read: IOPS=75.1k, BW=293MiB/s (308MB/s)(17.2GiB/60001msec)
   slat (nsec): min=761, max=1884.1k, avg=2652.56, stdev=1984.20
   clat (usec): min=55, max=13371, avg=782.53, stdev=128.74
    lat (usec): min=77, max=13377, avg=785.18, stdev=128.77
   clat percentiles (usec):
    |  1.00th=[  474],  5.00th=[  685], 10.00th=[  709], 20.00th=[  734],
    | 30.00th=[  758], 40.00th=[  766], 50.00th=[  783], 60.00th=[  799],
    | 70.00th=[  816], 80.00th=[  832], 90.00th=[  857], 95.00th=[  881],
    | 99.00th=[  938], 99.50th=[  971], 99.90th=[ 1139], 99.95th=[ 1336],
    | 99.99th=[ 6587]
  bw (  KiB/s): min=280752, max=358266, per=100.00%, avg=300339.15, stdev=1602.27, samples=480
  iops        : min=70188, max=89566, avg=75084.82, stdev=400.56, samples=480
 write: IOPS=25.1k, BW=98.0MiB/s (103MB/s)(5878MiB/60001msec); 0 zone resets
   slat (nsec): min=912, max=525562, avg=2967.64, stdev=1934.44
   clat (usec): min=35, max=18793, avg=196.68, stdev=139.03
    lat (usec): min=39, max=18796, avg=199.65, stdev=139.03
   clat percentiles (usec):
    |  1.00th=[  114],  5.00th=[  127], 10.00th=[  135], 20.00th=[  147],
    | 30.00th=[  157], 40.00th=[  167], 50.00th=[  180], 60.00th=[  190],
    | 70.00th=[  204], 80.00th=[  221], 90.00th=[  260], 95.00th=[  330],
    | 99.00th=[  537], 99.50th=[  635], 99.90th=[  996], 99.95th=[ 1352],
    | 99.99th=[ 6783]
  bw (  KiB/s): min=92336, max=121717, per=100.00%, avg=100324.64, stdev=729.36, samples=480
  iops        : min=23084, max=30429, avg=25081.16, stdev=182.34, samples=480
 lat (usec)   : 50=0.01%, 100=0.06%, 250=22.27%, 500=3.17%, 750=20.00%
 lat (usec)   : 1000=54.24%
 lat (msec)   : 2=0.22%, 4=0.01%, 10=0.02%, 20=0.01%
 cpu          : usr=2.30%, sys=8.87%, ctx=4464948, majf=0, minf=46
 IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.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.1%, 32=0.0%, 64=0.0%, >=64=0.0%
    issued rwts: total=4505067,1504862,0,0 short=0,0,0,0 dropped=0,0,0,0
    latency   : target=0, window=0, percentile=100.00%, depth=16
Run status group 0 (all jobs):
  READ: bw=293MiB/s (308MB/s), 293MiB/s-293MiB/s (308MB/s-308MB/s), io=17.2GiB (18.5GB), run=60001-60001msec
 WRITE: bw=98.0MiB/s (103MB/s), 98.0MiB/s-98.0MiB/s (103MB/s-103MB/s), io=5878MiB (6164MB), run=60001-60001msec
Disk stats (read/write):
 vda: ios=4493392/1501032, sectors=35947560/12009064, merge=30/98, ticks=3513055/290992, in_queue=3804050, util=83.93%

Alles anzeigen

davorzec

Zitat von meti

I think the main point is being misunderstood here. The fio benchmark was not the reason to assume there is a problem. The problem was noticed first in real-world usage, and the benchmark was only used afterwards to investigate the possible cause.
In my own experience, I have been running workloads on a weaker Het**zner VPS for more than a year without seeing this kind of storage-related degradation. I also had no issues with this Netcup server during the first week. The problem appeared only recently, which suggests something changed rather than simply being a case of unrealistic expectations about NVMe performance.
The fio results, along with other system information and observations, were provided through multiple support tickets over several days after no response was received. The concern is not only the performance issue itself, but also the lack of communication and feedback from support.
Even very small and less established providers usually acknowledge a support request within an hour or two. Waiting several days without even a basic response from a provider of this size is the frustrating part of this situation

Exactly.

I sent the first of three support tickets eight days ago, and I still have not received any response.

davorzec

Zitat von cysiek

So i performed same fio as davorzec on my RS 2000 (iddling)

Code

fio --name=mixed_workload --filename=~/fio_test.file --size=10G \
--rw=randrw --rwmixread=75 --bs=4k --ioengine=libaio --direct=1 \
--numjobs=4 --iodepth=16 --runtime=60 --time_based --group_reporting
mixed_workload: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=16
...
fio-3.39
Starting 4 processes
mixed_workload: Laying out IO file (1 file / 10240MiB)
Jobs: 4 (f=0): [f(4)][100.0%][r=284MiB/s,w=93.6MiB/s][r=72.7k,w=23.9k IOPS][eta 00m:00s]
mixed_workload: (groupid=0, jobs=4): err= 0: pid=500344: Mon Aug  3 21:52:35 2026
 read: IOPS=75.1k, BW=293MiB/s (308MB/s)(17.2GiB/60001msec)
   slat (nsec): min=761, max=1884.1k, avg=2652.56, stdev=1984.20
   clat (usec): min=55, max=13371, avg=782.53, stdev=128.74
    lat (usec): min=77, max=13377, avg=785.18, stdev=128.77
   clat percentiles (usec):
    |  1.00th=[  474],  5.00th=[  685], 10.00th=[  709], 20.00th=[  734],
    | 30.00th=[  758], 40.00th=[  766], 50.00th=[  783], 60.00th=[  799],
    | 70.00th=[  816], 80.00th=[  832], 90.00th=[  857], 95.00th=[  881],
    | 99.00th=[  938], 99.50th=[  971], 99.90th=[ 1139], 99.95th=[ 1336],
    | 99.99th=[ 6587]
  bw (  KiB/s): min=280752, max=358266, per=100.00%, avg=300339.15, stdev=1602.27, samples=480
  iops        : min=70188, max=89566, avg=75084.82, stdev=400.56, samples=480
 write: IOPS=25.1k, BW=98.0MiB/s (103MB/s)(5878MiB/60001msec); 0 zone resets
   slat (nsec): min=912, max=525562, avg=2967.64, stdev=1934.44
   clat (usec): min=35, max=18793, avg=196.68, stdev=139.03
    lat (usec): min=39, max=18796, avg=199.65, stdev=139.03
   clat percentiles (usec):
    |  1.00th=[  114],  5.00th=[  127], 10.00th=[  135], 20.00th=[  147],
    | 30.00th=[  157], 40.00th=[  167], 50.00th=[  180], 60.00th=[  190],
    | 70.00th=[  204], 80.00th=[  221], 90.00th=[  260], 95.00th=[  330],
    | 99.00th=[  537], 99.50th=[  635], 99.90th=[  996], 99.95th=[ 1352],
    | 99.99th=[ 6783]
  bw (  KiB/s): min=92336, max=121717, per=100.00%, avg=100324.64, stdev=729.36, samples=480
  iops        : min=23084, max=30429, avg=25081.16, stdev=182.34, samples=480
 lat (usec)   : 50=0.01%, 100=0.06%, 250=22.27%, 500=3.17%, 750=20.00%
 lat (usec)   : 1000=54.24%
 lat (msec)   : 2=0.22%, 4=0.01%, 10=0.02%, 20=0.01%
 cpu          : usr=2.30%, sys=8.87%, ctx=4464948, majf=0, minf=46
 IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.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.1%, 32=0.0%, 64=0.0%, >=64=0.0%
    issued rwts: total=4505067,1504862,0,0 short=0,0,0,0 dropped=0,0,0,0
    latency   : target=0, window=0, percentile=100.00%, depth=16
Run status group 0 (all jobs):
  READ: bw=293MiB/s (308MB/s), 293MiB/s-293MiB/s (308MB/s-308MB/s), io=17.2GiB (18.5GB), run=60001-60001msec
 WRITE: bw=98.0MiB/s (103MB/s), 98.0MiB/s-98.0MiB/s (103MB/s-103MB/s), io=5878MiB (6164MB), run=60001-60001msec
Disk stats (read/write):
 vda: ios=4493392/1501032, sectors=35947560/12009064, merge=30/98, ticks=3513055/290992, in_queue=3804050, util=83.93%

Alles anzeigen

Those are good results.

Where is your server located?

cysiek

Same as Yours (if I'm not mistaken) - Vienna.
They definetly did some fixes or someone stopped killing it. This is not direct nvme, it's behind some network backend.

I performed it also on one of my other VPS machines (you know, "french one", since company name is forbidden here

Code

fio --name=mixed_workload --filename=~/fio_test.file --size=10G \
--rw=randrw --rwmixread=75 --bs=4k --ioengine=libaio --direct=1 \
--numjobs=4 --iodepth=16 --runtime=60 --time_based --group_reporting
mixed_workload: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=16
...
fio-3.39
Starting 4 processes
mixed_workload: Laying out IO file (1 file / 10240MiB)
Jobs: 4 (f=4): [m(4)][100.0%][r=117MiB/s,w=39.3MiB/s][r=30.0k,w=10.1k IOPS][eta 00m:00s]
mixed_workload: (groupid=0, jobs=4): err= 0: pid=673285: Mon Aug  3 22:13:12 2026
 read: IOPS=30.0k, BW=117MiB/s (123MB/s)(7043MiB/60004msec)
   slat (usec): min=2, max=3946, avg=10.38, stdev= 9.88
   clat (usec): min=134, max=51014, avg=2052.77, stdev=245.19
    lat (usec): min=165, max=51033, avg=2063.16, stdev=245.40
   clat percentiles (usec):
    |  1.00th=[ 1516],  5.00th=[ 1811], 10.00th=[ 1893], 20.00th=[ 1975],
    | 30.00th=[ 2008], 40.00th=[ 2040], 50.00th=[ 2073], 60.00th=[ 2089],
    | 70.00th=[ 2114], 80.00th=[ 2147], 90.00th=[ 2180], 95.00th=[ 2245],
    | 99.00th=[ 2409], 99.50th=[ 2606], 99.90th=[ 3720], 99.95th=[ 4424],
    | 99.99th=[ 5932]
  bw (  KiB/s): min=113270, max=144007, per=100.00%, avg=120335.01, stdev=672.90, samples=476
  iops        : min=28317, max=36001, avg=30083.66, stdev=168.21, samples=476
 write: IOPS=10.1k, BW=39.3MiB/s (41.2MB/s)(2359MiB/60004msec); 0 zone resets
   slat (usec): min=2, max=3972, avg=11.43, stdev=11.19
   clat (usec): min=2, max=17159, avg=180.09, stdev=155.39
    lat (usec): min=41, max=17182, avg=191.52, stdev=155.85
   clat percentiles (usec):
    |  1.00th=[   55],  5.00th=[   69], 10.00th=[   79], 20.00th=[   95],
    | 30.00th=[  110], 40.00th=[  126], 50.00th=[  143], 60.00th=[  163],
    | 70.00th=[  192], 80.00th=[  235], 90.00th=[  314], 95.00th=[  404],
    | 99.00th=[  701], 99.50th=[  873], 99.90th=[ 1549], 99.95th=[ 2073],
    | 99.99th=[ 3916]
  bw (  KiB/s): min=36752, max=50000, per=100.00%, avg=40304.07, stdev=412.25, samples=476
  iops        : min= 9188, max=12500, avg=10075.93, stdev=103.05, samples=476
 lat (usec)   : 4=0.01%, 10=0.01%, 20=0.01%, 50=0.12%, 100=5.81%
 lat (usec)   : 250=14.78%, 500=3.75%, 750=0.62%, 1000=0.21%
 lat (msec)   : 2=20.13%, 4=54.52%, 10=0.05%, 20=0.01%, 50=0.01%
 lat (msec)   : 100=0.01%
 cpu          : usr=5.14%, sys=13.44%, ctx=1376674, majf=0, minf=47
 IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.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.1%, 32=0.0%, 64=0.0%, >=64=0.0%
    issued rwts: total=1803037,603923,0,0 short=0,0,0,0 dropped=0,0,0,0
    latency   : target=0, window=0, percentile=100.00%, depth=16
Run status group 0 (all jobs):
  READ: bw=117MiB/s (123MB/s), 117MiB/s-117MiB/s (123MB/s-123MB/s), io=7043MiB (7385MB), run=60004-60004msec
 WRITE: bw=39.3MiB/s (41.2MB/s), 39.3MiB/s-39.3MiB/s (41.2MB/s-41.2MB/s), io=2359MiB (2474MB), run=60004-60004msec
Disk stats (read/write):
 sda: ios=1802735/603988, sectors=14421952/4832152, merge=6/26, ticks=3676582/96701, in_queue=3773289, util=64.59%

Alles anzeigen

ASS

Zitat von andreas.

Try running the same test again with a file size of 10 GB instead of 4 GB.

Wie oft kommen solche Dateigrößen in der Realität vor?

Bei meinen Serveranwendungen eher selten.

Kauft ihr Server um Benchmarks bei Grenzfällen zu testen, oder um sie zu benutzen?

Falzo

Zitat von ASS

Wie oft kommen solche Dateigrößen in der Realität vor?
Bei meinen Serveranwendungen eher selten.
Kauft ihr Server um Benchmarks bei Grenzfällen zu testen, oder um sie zu benutzen?

Das hast Du falsch verstanden

Fio simuliert den zufälligen Zugriff auf ganz viele kleine (4k große) Blöcke/Dateien...

Die Testdatei sollte dabei ggf. aber größer sein als der RAM, sonst wird sie möglicherweise gecached und der ganze Test findet gar nicht gegen das storage statt.

Auch die Auswahl der ganzen Parameter ist wichtig, um direktes Schreiben zu erzwingen bspw. , kommt ganz drauf an, was genau man messen will.

Die meisten verstehen aber die Unterschiede zwischen Blockgrößen, IOps und Bandbreite eh nicht, von daher sind fios mit immer gleichen optionen (wie zB im yans integriert) zwar eine Vergleichsbasis, aber zur Problemanalyse mot Vorsicht zu geniessen.

So oder so, der storage bei netcup is shared, vermutlich ein großes NVMe storage array/cluster das dann verschiedene compute noden angebunden wird. Da schwankt die performance schonmal mit hunderten Gästen drauf, die alle 500k nvme iops erwarten, als wären sie allein auf einem dedi

webdesignheld

Zitat von Falzo

Die Testdatei sollte dabei ggf. aber größer sein als der RAM

mein VPS hat 2GB Ram - da kann ich ja dann mit 790000 blocks testen.

Falzo

Zitat von webdesignheld

mein VPS hat 2GB Ram - da kann ich ja dann mit 790000 blocks testen.

ja so ungefähr. zumindest bezog sich vermutlich die Aussage mit den 10 GB darauf...

spezielle Optionen wie zB --direct=1 sind dann aber ggf. noch besser und welches model (libaio) verwendet, wieviel jobs parallel, welche iodepth usw.

webdesignheld

Zitat von Falzo

spezielle Optionen wie zB --direct=1 sind dann aber ggf. noch besser und welches model (libaio) verwendet, wieviel jobs parallel, welche iodepth

ich geh immer zu pagespeed.web.dev und wenn die Seite in 1 Sekunde mobil lädt ist die Server Festplatte ok.

ASS

Zitat von Falzo

Das hast Du falsch verstanden

Jein.

Mein flame bezog sich auf diese ganzen "präventivtests" im Allgemeinen.

Ich glaube, bei vielen Providern machen solche sinnlosen Tests mehr Last, als die Dienste, die auf den Servern eigentlich laufen sollen.

Falzo

Zitat von ASS

Jein.
Mein flame bezog sich auf diese ganzen "präventivtests" im Allgemeinen.
Ich glaube, bei vielen Providern machen solche sinnlosen Tests mehr Last, als die Dienste, die auf den Servern eigentlich laufen sollen.

ah, verstehe, sorry, da kam der sarkasmus nicht bei mir an

und ich stimme absolut zu, die Tests werden viel zu häufig fehlinterpretiert oder in falschen Situationen laufen gelassen.

IOps im speziellen werden eh überbewertet. oft wird "Datenbank" als Grund dafür genannt, warum man IOps braucht. solange es sich um keine file-based DB handelt, halte ich das zB für den absoluten Quatsch. Eine Datenbank lebt von indexen und caching. das meiste findet also im RAM statt, oder man setzt die Datenbanken schlicht falsch ein. nur mal so als Beispiel... aber ich hab eh nur limited understanding, von daher

meti

I've been running my project on this server again for the past few hours, and so far, I haven't experienced any of the previous issues.

davorzec

Yes, it seems fine now.