Same here with my RS 16000. No changes on my end. Looks like some misconfiguration on netcups end.
Wenn ich mir auf einem RS 8000 G11 folgendes Ergebnis ([r=475,w=475 IOPS]) so anschaue, so sieht es so aus, dass auf dem Host eher nur SATA SSD´s im RAID 1 Verbund verbaut sind.
fiotest: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1
fio-3.19
Starting 1 process
fiotest: Laying out IO file (1 file / 10240MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=1902KiB/s,w=1902KiB/s][r=475,w=475 IOPS][eta 00m:00s]
fiotest: (groupid=0, jobs=1): err= 0: pid=1146: Thu Jul 30 20:55:39 2026
read: IOPS=450, BW=1803KiB/s (1847kB/s)(106MiB/60001msec)
slat (usec): min=5, max=211, avg=13.17, stdev= 5.70
clat (nsec): min=861, max=8901.3k, avg=185372.90, stdev=95952.63
lat (usec): min=24, max=8926, avg=198.70, stdev=96.80
clat percentiles (usec):
| 1.00th=[ 20], 5.00th=[ 24], 10.00th=[ 29], 20.00th=[ 159],
| 30.00th=[ 178], 40.00th=[ 190], 50.00th=[ 202], 60.00th=[ 215],
| 70.00th=[ 227], 80.00th=[ 241], 90.00th=[ 262], 95.00th=[ 277],
| 99.00th=[ 314], 99.50th=[ 338], 99.90th=[ 537], 99.95th=[ 750],
| 99.99th=[ 1418]
bw ( KiB/s): min= 1304, max= 2208, per=100.00%, avg=1804.93, stdev=185.14, samples=119
iops : min= 326, max= 552, avg=451.23, stdev=46.30, samples=119
write: IOPS=450, BW=1802KiB/s (1845kB/s)(106MiB/60001msec); 0 zone resets
slat (nsec): min=5958, max=70646, avg=14046.75, stdev=5371.07
clat (usec): min=422, max=6578, avg=2003.36, stdev=337.57
lat (usec): min=429, max=6593, avg=2017.56, stdev=338.17
clat percentiles (usec):
| 1.00th=[ 1172], 5.00th=[ 1369], 10.00th=[ 1663], 20.00th=[ 1795],
| 30.00th=[ 1876], 40.00th=[ 1942], 50.00th=[ 2008], 60.00th=[ 2073],
| 70.00th=[ 2147], 80.00th=[ 2245], 90.00th=[ 2376], 95.00th=[ 2507],
| 99.00th=[ 2900], 99.50th=[ 3228], 99.90th=[ 4178], 99.95th=[ 4555],
| 99.99th=[ 5866]
bw ( KiB/s): min= 1552, max= 2144, per=100.00%, avg=1803.80, stdev=116.83, samples=119
iops : min= 388, max= 536, avg=450.95, stdev=29.21, samples=119
lat (nsec) : 1000=0.01%
lat (usec) : 20=0.70%, 50=7.21%, 100=0.18%, 250=34.54%, 500=7.36%
lat (usec) : 750=0.05%, 1000=0.06%
lat (msec) : 2=24.89%, 4=24.95%, 10=0.06%
cpu : usr=0.48%, sys=1.88%, ctx=54076, majf=0, minf=16
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.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.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=27050,27024,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
READ: bw=1803KiB/s (1847kB/s), 1803KiB/s-1803KiB/s (1847kB/s-1847kB/s), io=106MiB (111MB), run=60001-60001msec
WRITE: bw=1802KiB/s (1845kB/s), 1802KiB/s-1802KiB/s (1845kB/s-1845kB/s), io=106MiB (111MB), run=60001-60001msec
Disk stats (read/write):
vda: ios=26979/80919, merge=0/26970, ticks=4816/51350, in_queue=105257, util=94.05%
real 1m24,772s
user 0m2,322s
sys 0m15,752sSATA SSD´s im RAID 1 Verbund verbaut
Bei den momentanen Preisen schaut man eben, was noch so im Keller liegt. 
Same issue with my RS 1000 G12. Support has been unresponsive for days
Any changes?
Did the offer you bought specify any kind of IOps guarantue or did it just mention, that the underlying shared storage will consist of NVMe ?
Are you just complaining about an artificial benchmark number or is in anyway affecting your workload?
I would suggest to collect logs of high iowait impact on your real world use case, if you want to have something solid to base your complaints towards support on.
Or maybe make use of the satisfaction guarantue and quickly back out before its too late and you are stuck with a product you don't like.
Did the offer you bought specify any kind of IOps guarantue or did it just mention, that the underlying shared storage will consist of NVMe ?
Are you just complaining about an artificial benchmark number or is in anyway affecting your workload?
I would suggest to collect logs of high iowait impact on your real world use case, if you want to have something solid to base your complaints towards support on.
Or maybe make use of the satisfaction guarantue and quickly back out before its too late and you are stuck with a product you don't like.
This is a remarkably poor take and adds absolutely nothing useful to the discussion.
If your understanding of the subject is this limited, why bother replying at all?
Alles anzeigenMy latest FIO test still shows very poor storage performance:
Metric Result
Read IOPS 14,716
Write IOPS 4,922
Combined IOPS ≈19,638
Read bandwidth 57.4 MiB/s
Write bandwidth 19.2 MiB/s
Average read latency 2.99 ms
Average write latency 4.06 ms
99th percentile read latency 10.99 ms
99th percentile write latency 12.63 ms
Disk utilization 64.8%Should netcup be concerned about potential legal consequences in Germany if its servers are advertised as using high-performance NVMe storage while customers receive substantially lower performance, especially when support tickets concerning the issue remain unanswered for several days?
Did you happen to test the RAM instead of the virtual NVMe?
This is a remarkably poor take and adds absolutely nothing useful to the discussion.
If your understanding of the subject is this limited, why bother replying at all?
It isn't a poor take, just because it doesn't support the narrative you would want.
You started pointing towards legal consequences, so I simply would want to know what you think which kind of guarantues or promises they broke, that would suggest so.
Just because _you_ had high expectations while no real numbers or SLA is actually written somewhere you are now disappointed.
And if being called out for it, it is a poor take.
Maybe just try to manage your expectations better to not get disappointed again. And take the satisfaction guarantue. Trust me. They won't change the limits for you. Best case they migrate you to another node but again there will be no guarantue and you'd still be disappointed.
Maybe this product or provider simply isn't for you.
No, sir. This is the exact command used for my latest test:
fio --name=mixed_workload --filename=/root/fio_test.file --size=10G \
--rw=randrw --rwmixread=75 --bs=4k --ioengine=libaio --direct=1 \
--numjobs=4 --iodepth=16 --runtime=60 --time_based --group_reportingI am not complaining blindly based on an fio benchmark. I first noticed terrible performance under real-world workloads on my 24 webistes. I then ran fio to investigate the cause, and the results pointed to storage performance as the likely bottleneck.
If you see a specific technical problem with the test command or methodology, please point it out.
Did you get the result while experiencing the terrible performance?
If disk/iops is the bottleneck you should look at iowait and iostats while the performance is bad.
If you run fio in parallel to 24 heavy loaded websites and it still manages to get >10k in 4k I'd say there is plenty of room and that would actually prove the opposite, disk IO is not the bottleneck.
My little 1,94 Euro/Month G8 VPS
Try running the same test again with a file size of 10 GB instead of 4 GB. You’ll be surprised at how quickly the I/O performance drops off.
Did the offer you bought specify any kind of IOps guarantue or did it just mention, that the underlying shared storage will consist of NVMe ?
Are you just complaining about an artificial benchmark number or is in anyway affecting your workload?
I would suggest to collect logs of high iowait impact on your real world use case, if you want to have something solid to base your complaints towards support on.
Or maybe make use of the satisfaction guarantue and quickly back out before its too late and you are stuck with a product you don't like.
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
