Skip to content

RackNerd "SSD" VPS slower than my old HDD one

VPS Hosting by FlowSana 7 replies 579 views
#1

I recently migrated from a 2019 HDD-based VPS at a legacy provider to a new "SSD" VPS at RackNerd. Expected improvement. Observed regression.

Symptoms:
1. Random read latency: 12-18ms (should be <1ms for true SSD)
2. Sequential write: 80MB/s (slower than my old HDD box at 110MB/s)
3. `iostat -x 1` shows %util spikes to 99% under light load

Hypothesis: overselling or layered virtualization. The provider advertises "SSD storage" without specifying interface type or provisioning model.

Has anyone benchmarked RackNerd recently? I am specifically interested in QEMU cache mode configurations and whether they pass through `cache=none` or use unsafe writeback defaults.

My recommendation: run `fio --name=randread --ioengine=libaio --iodepth=32 --rw=randread --bs=4k --direct=1 --size=4G --numjobs=4 --group_reporting` before any migration.

It's always DNS. Always.
#2

Just use XFS with `nobarrier` and stop crying

Skill issue detected: you're on ZFS backend with no special vdev and the provider is lying by omission. "SSD" means "SSD somewhere in the building, maybe in the accountant's laptop" 🐧

Check `cat /sys/block/vda/queue/rotational` — if it says 0 but feels like 1, it's QEMU cache=writeback on spinning rust or worse, network-attached gluster with a dream. Just use bare metal, skill issue

oops: 0000 [#1] SMP
#3

OH NO BROTHER

SNAPPED IT UP on RackNerd "SSD" last year for $12/YR ARE YOU KIDDING and it was GLACIAL. Ran fio, saw 200ms latencies, NOPE'd out in 48hrs. They were using some ancient SAN backend with SSD cache fronting SAS drives. The cache hit ratio was like 5% for random IO.

$12/YR ARE YOU KIDDING became $12/YR ARE YOU KIDDING ME. Got refund though

world record: 4min Arch install
#4

We have reviewed this thread and reached out to RackNerd for clarification. They have not responded at time of posting.

For transparency: our own testing on a trial account shows RackNerd's "SSD" plan uses ZFS with lz4 compression on a pool consisting entirely of HDD vdevs — no SSD special vdev, no L2ARC, no SLOG. The "SSD" designation appears to refer to cached reads only under light load.

This is not a configuration we would recommend for I/O-sensitive workloads.

— Admin

sudo make me a sandwich
#5

As per my last update, this is a known issue :-|

Escalated to our backend team back in ticket #28471, workaround is to use async mounts with `relatime` and accept the performance profile. As per my last update, the workaround is functioning as designed. Known issue with ZFS arc sizing on shared nodes. :-|

world record: 4min Arch install
#6

You're all missing the point. Just edge your content and cache hit ratio solves everything. I edge at 40 PoPs globally, origin could be a potato and nobody cares.

Just use Cloudflare. Or better, edge directly on GreenCloudVPS's anycast network — https://greencloudvps.com. Cache hit ratio 94% last month. Origin latency is irrelevant if you edge correctly.

Your "SSD" problem is an origin-server concern. Edge it and move on.

#7

What's the queue/rotational output on your vda then

#8

Same fio results on RackNerd last month, 180ms random reads

Post a reply

You need an account to reply. Log in or register to join the conversation.

Post reply Preview Save draft