Solana VDS: pinned cores, isolated RAM, zero CPU steal time

On paper a VDS and a VPS are the same product: a Linux VM you SSH into, with CPU and RAM and disk. The provisioning workflow is identical. The price tag is the obvious difference. The question is what the extra spend actually buys you. Three things, all about tail latency rather than median.

First, dedicated cores. A VPS hands out vCPU on a fair-share scheduler. If three other tenants on your host go idle, you get their cycles for free. If one of them runs hot, the scheduler still gives you your fair share, but each context switch costs a cache reload and a few microseconds of wall-clock latency. On a workload at 10% CPU you don't notice. On a Yellowstone gRPC consumer pulling 60k messages per second, you measure it. A VDS pins specific physical cores to your VM. Nobody else schedules on them, ever.

Second, isolated RAM with NUMA awareness. A VPS's memory is allocated wherever the hypervisor finds room. On a dual-socket host that can mean half your pages are on the remote socket with a 90ns access penalty per cache miss. A VDS pins the RAM allocation to the same NUMA node as your cores. The penalty disappears.

Third, committed network bandwidth. VPS uplinks are shared with fair-share QoS. VDS uplinks have a committed information rate at the host NIC, with strict QoS, so a noisy neighbor can't crowd you out during a memecoin spike. Consistent network jitter is what keeps p99 latency tight, and tight p99 is what keeps the bot profitable on the bad days.

Concrete numbers: on a vps.pro (8 vCPU shared), under peak load, CPU steal time can reach 1-3% during neighbor bursts. On a vds.standard (8 dedicated EPYC cores), steal time stays at 0.00% by contract. If you want the cheaper tier first, start on VPS and watch your mpstat steal-time graphs. Once they're non-zero during peak hours, move up.

“Dedicated” is meaningless without saying what it means at the kernel level. Here is the unglamorous version.

On a vds.performance, your VM lives on a libvirt domain configured with cputune pinning each vCPU to a specific physical core. Hyperthreading is off, so each vCPU is a real core, not a sibling thread. Cgroup v2 enforces the pinning at the kernel level, not just at libvirt launch. The host's IRQ affinity mask is set to keep network interrupts on a different core set, so your bot threads never get preempted by an incoming packet handler.

RAM is allocated using numatune with a strict policy on the node where your cores live. Huge pages are on by default for vds.performance and vds.max; the TLB hit rate on a busy indexer goes from 70% to 99%, which compounds into measurable throughput on disk-heavy queries. NVMe is a dedicated namespace on a host-attached PCIe Gen4 drive, not partitioned with another tenant.

The visible result: when you load test a vds.performance versus a vps.enterprise (same 16 vCPU count on paper), the VPS shows a long tail in response time histograms, with occasional 30-80ms spikes during neighbor activity. The VDS tail collapses into a tight band inside 5ms of the median. Same code, same network, different host class. That tail is the entire reason this tier exists.

Every VDS includes a benchmark script at /opt/nln/bench.sh that runs sysbench, fio, STREAM, and a synthetic gRPC consumer for 10 minutes and uploads the results to your account. If the numbers look wrong, open a ticket and we fix it.

On a shared VPS, a neighbor's CPU burst causes context switches that add 10-80ms of tail latency to your workload. This is not theoretical. It is the single most common reason teams upgrade from VPS to VDS.

The mechanism: when the hypervisor decides to schedule another tenant's vCPU on a core you were using, your running thread gets a VM-exit. The hypervisor saves your register state, loads the neighbor's state, and hands the core over. When you get it back, your L1 and L2 caches are cold. A cache miss on DDR5 costs roughly 90-120ns on the local NUMA node, but the cumulative effect across thousands of memory accesses in a single gRPC frame decode adds up to tens of milliseconds of wall-clock delay.

During the US market open overlap (13:00-17:00 UTC), Solana chain activity peaks. This is exactly when your VPS neighbors also increase CPU usage, because everyone's bots are running. Your p99 jumps from 5ms to 45ms. On a VDS, the p99 stays at 5ms because the cores are physically yours and the scheduler cannot take them away.

The p50 is the same because at the median, the hypervisor is not contending. The p99 is 7x different because the tail is where contention lives. If you're not seeing this pattern on your VPS, stay on VPS. If you are, the VDS upgrade removes the problem completely.

The migration is straightforward because both VPS and VDS run in the same Frankfurt location on the same private VLAN. No DNS changes, no firewall reconfiguration, no datacenter move.

1. Identify the signal. Run mpstat -P ALL 1 300 during peak Solana hours. If any core shows steal above 1%, that is your migration trigger. Also check your application p99: if it's more than 3x your p50, the hypervisor is adding latency you can't tune away.
2. Choose your VDS tier. Match your current VPS vCPU count to the nearest VDS: vps.starter (4 vCPU) maps to vds.standard (8 cores, $245/mo). vps.pro (8 vCPU) also maps to vds.standard. vps.enterprise (16 vCPU) maps to vds.performance (16 cores, $495/mo). You get more cores at the same or next tier, not fewer.
3. Provision the VDS. Same API, same dashboard. The VDS boots in 2-3 minutes with your SSH key and preferred OS image. It lands on the same private VLAN as your existing VPS.
4. Migrate data. For stateless bots: just deploy the same code and systemd unit. For stateful workloads (Postgres, account data): rsync -avz --progress over the private VLAN. The 10 Gbps link means a 100 GB database transfers in under 90 seconds.
5. Verify isolation. Run /opt/nln/bench.sh and check that steal time is 0.00%. Compare your p99 before and after. It should drop to within 2x of p50.
6. Decommission the VPS. Once the VDS is verified, shut down the VPS via the API or dashboard. Billing stops immediately. No prorated overlap if you do it within the same billing cycle.

Total migration time: 15-30 minutes for a stateless bot, 1-2 hours for a stateful workload with a database. No downtime if you keep the VPS running until the VDS is verified.

The three workloads that move from VPS to VDS most often, and which tier fits each.

Need more than 32 cores or 128 GB RAM? That is the crossover point. Bare-metal at this performance level is cheaper per unit of compute: nln.metal.base gives you 16 EPYC cores at 3.0 GHz with 128 GB RAM and 4 NVMe drives for $692/mo. If you don't need virtualization features, physical hardware wins above vds.max.

The honest comparison table.

OVH wins on raw price, but their Gravelines location is 11-15ms from Frankfurt validators. Latitude.sh sells the same Frankfurt geography at roughly similar cost to our vds.performance, without our private RPC VLAN. The last row is the crossover point: nln.metal.base at $692/mo gives you 16 EPYC cores, 128 GB RAM, and 4 NVMe drives. If you don't need virtualization, bare-metal is cheaper at this performance level. See bare-metal for the full breakdown, or talk to sales for committed annual pricing.