You can distinguish between a VDS and a VPS by checking for CPU steal time and examining the hypervisor resource allocation via the /proc filesystem. At Hostna, we operate infrastructure where the distinction is defined by whether physical CPU threads are pinned to your instance or shared across a pool of other virtual machines. While both use virtualization, the underlying scheduling of the CPU determines the consistency of your workloads.
| Symptom | Probable Cause | Diagnostic Command |
|---|---|---|
Fluctuating TTFB during peak hours |
CPU oversubscription on a VPS |
top -bn1 | grep "%Cpu(s):" |
High %st value in top |
Noisy neighbor stealing cycles | vmstat 1 5 |
Random I/O wait spikes |
Shared NVMe bandwidth contention |
iostat -xz 1 |
The Primary Mechanism: CPU Steal Time
The most reliable way to identify a VPS environment is the presence of CPU steal time. In a virtualized environment, the hypervisor manages multiple virtual machines on a single physical host. When a VPS requests CPU cycles but the physical processor is busy servicing another tenant, the time spent waiting is recorded as steal time. You can observe this by running top and looking at the %st column in the CPU summary line.
A VDS or a machine with dedicated resource allocation should ideally show a %st value of 0.0 consistently, even under heavy load. This is because the hypervisor pins specific physical cores or threads to that virtual machine, ensuring that no other process can claim those execution units. If you see steal time reaching 5% or 10% during your application’s busy periods, you are likely on a shared VPS plan where the physical hardware is overprovisioned.
# Check for CPU steal time in a single batch
top -bn1 | grep "%Cpu(s):" | awk '{print $16}'The awk '{print $16}' command extracts the steal time field from the top output. If this number is greater than zero while your own CPU usage is low, it indicates that the host is heavily loaded with other tenants. Understanding this mechanism is vital for maintaining service level commitments for high-traffic applications.
Identifying the Hypervisor and Virtualization Type
The type of virtualization technology used can also provide clues. Technologies like Kernel-based Virtual Machine (KVM) are used for both VPS and VDS, but the configuration differs. You can use the virt-what or lscpu commands to see how the kernel perceives the hardware. A VDS often presents as a more transparent layer to the guest operating system.
Run lscpu and look for the Hypervisor vendor and Virtualization type fields. If the vendor is KVM, you are likely in a modern virtualized environment. To go deeper, check the /proc/cpuinfo file. In a VDS, the model name often matches the actual physical CPU of the host (such as an AMD EPYC or Intel Xeon), whereas some VPS configurations might mask this or show a generic QEMU virtual CPU string.
# Check the CPU model and hypervisor details
lscpu | grep -E "Model name|Hypervisor|Virtualization"If you are managing Linux kernel parameters, knowing the hypervisor type helps in tuning the kvm_clock and other clock sources to prevent drift. The platform at Hostna ensures that even on virtualized tiers, the clock source remains stable for database integrity.
Memory Management and the OOM Killer
Another differentiator is how memory is allocated. A VPS might use memory ballooning, a technique where the hypervisor can reclaim unused RAM from the guest to give to another virtual machine. In contrast, a VDS typically has its memory fully reserved. You can check for signs of memory pressure that do not originate from your own processes by looking at the kernel logs for OOM killer activity.
A PHP-FPM pool with pm.max_children = 10 and a 512 MB memory_limit can claim 5 GB in the worst case, which is why a 4 GB machine that looks idle can still be killed by the OOM killer during one traffic spike — the ceiling is max_children x memory_limit, not average usage. If your mysqld process is frequently terminated despite having free RAM shown in free -m, it might be due to the host’s memory overcommitment ratio.
To avoid these issues, refer to our technical documentation on optimizing memory limits for various workloads. For instance, an innodb_buffer_pool_size set to roughly three quarters of the machine’s RAM is a common starting point, but on a VPS with ballooning, this can be risky if the host decides to reclaim pages.
Disk I/O and Throughput Benchmarking
Storage performance is often the most contested resource on a shared host. While a VPS might offer high burst speeds, the sustained NVMe IOPS are usually limited by cgroup definitions to prevent a single user from saturating the storage backplane. You can measure this using a tool like fio or dd, though fio is more accurate for testing random read and write performance.
If you notice that your disk latency increases significantly when other sites on the same physical host are active, you are experiencing the noisy neighbor effect. On a VDS or bare metal hardware, the disk controller or a specific portion of the NVMe array is often dedicated to your instance, leading to much lower jitter. This is critical for applications like Nginx when serving large static files, as detailed in the ngx_http_core_module documentation regarding sendfile and aio.
# Test random write IOPS
fio --name=random-write --ioengine=libaio --rw=randwrite --bs=4k --size=1g --numjobs=1 --runtime=60 --time_based --end_fsync=1A VDS will show a very tight distribution of latency results, whereas a VPS will likely show a wider variance. This variance is the “jitter” that can cause intermittent slow page loads even when your application code is optimized.
Verifying Resources via the Dashboard
Finally, the most straightforward way to confirm your server type is to check the plan you are on within the control panel. While technical commands provide proof of the current state, the billing and product description in your account will specify the resource commitment. If you are moving your data from a VPS to a VDS, you should perform these tests before and after the move to verify the performance gain.
If you find that your steal time is consistently high and it is impacting your production environment, it may be time to upgrade to a tier with dedicated cores. Our German-hosted stack is designed to provide clear visibility into these metrics so you can make informed decisions about your scaling needs. If the commands above show high %st but the dashboard indicates a VDS, contact support with the output of top and lscpu for a deep investigation into the hypervisor node’s health.
Distinguishing between these two types of hosting is not just about price; it is about the predictability of the execution environment. By using top, lscpu, and fio, you can move past marketing labels and understand exactly what the hardware is doing for your application at any given moment.
This article was drafted with AI assistance from Hostna’s own research pipeline and published without individual review. Tell us if anything here is wrong.