VPS Oversold Detection Methods: Practical Steal Time and Disk Cache Cliff Testing
Overselling is a common phenomenon in the VPS industry, but excessive overselling can significantly affect performance. This article provides an actionable detection method from two dimensions: CPU Steal Time and disk Cache cliff, helping you determine whether your VPS is over-oversold, and offers coping strategies.
By continuously monitoring CPU Steal Time and disk Cache cliff phenomena, combined with stress testing, you can effectively identify over-oversold VPS, stop losses in time, and optimize deployment strategies.
Why Detect VPS Overselling?
A VPS (Virtual Private Server) is created by partitioning physical server resources using virtualization technology. Overselling refers to the practice where the total virtual resources sold by a provider exceed the physical resource limits; this is a common practice in the IDC industry. Reasonable overselling can reduce costs, but excessive overselling can lead to CPU contention, soaring disk I/O latency, and even the 'noisy neighbor' problem.
As users, we cannot directly view the provider's overselling configuration, but we can indirectly infer it from the patterns of system metrics. Among them, CPU Steal Time and disk cache cliff are the two most direct and effective signals.
Core Metric 1: CPU Steal Time
What is Steal Time?
In Linux systems, the steal or st field represents the percentage of time that the virtual machine's CPU is preempted by the hypervisor (host). When physical CPU resources are insufficient, the hypervisor forcibly schedules, causing your VPS to be unable to obtain the CPU time it deserves. This waiting time is Steal Time.
High Steal Time means your VPS is "queuing for CPU" and performance suffers.
How to view Steal Time?
Use the top command and check the st value in the %Cpu(s) line:
top -n 1 | grep '%Cpu'Example output:
%Cpu(s): 5.1 us, 2.0 sy, 0.0 ni, 92.0 id, 0.0 wa, 0.9 hi, 0.0 si, 0.0 stHere, st is Steal Time. You can also use the vmstat command and pay attention to the st column (requires root privileges):
vmstat 1 5Threshold Criteria
- Sustained above 5%: Indicates the host CPU is overloaded, and your VPS is starting to be affected.
- Peaks above 10%: Significant performance degradation may occur, especially for tasks requiring sustained computation.
- Long-term exceeding 20%: This constitutes severe overselling; consider switching providers.
Stress Test Simulation
Simply looking at the Steal Time when idle may not be obvious. It is recommended to use the stress tool to simulate CPU load and observe how Steal Time behaves under pressure:
# Install stress (Debian/Ubuntu)
apt install stress -y
# Load all CPU cores for 60 seconds
stress --cpu $(nproc) --timeout 60 &
# Run top simultaneously for observation
sleep 5 && top -d 2 | grep '%Cpu'If the st value spikes under full load, it indicates that physical CPU resources are being heavily preempted by other VPS instances, indicating severe oversubscription.
Core Metric 2: The Disk Cache Cliff
What is the Disk Cache Cliff?
The disk I/O performance of a VPS is highly dependent on the cache in the host machine's memory. When there is a cache hit, read and write speeds are extremely fast; when there is a cache miss (especially during sudden heavy read/write activity), the physical disk speed becomes the bottleneck, and performance drops by orders of magnitude, forming a "cliff".
If there are too many VPS instances running on the host, the proportion of cache available to each VPS decreases, making it easier to trigger the cliff effect.
How to detect disk Cache cliff?
Use hdparm or dd to test disk read/write speed and observe speed fluctuations.
1. Simple test:
# 写入测试（512MB文件）
time dd if=/dev/zero of=testfile bs=1M count=512 conv=fdatasync
# 读取测试（清缓存后）
echo 3 > /proc/sys/vm/drop_caches # 需要root，清Page Cache
time dd if=testfile of=/dev/null bs=1M count=512Record the speed difference between the first test and subsequent tests. If the first write speed is very fast (due to write cache) and then drops sharply, it indicates that the cache capacity is limited and contention is severe.
2. Use fio for more precise testing:
# 安装fio（Debian/Ubuntu）
apt install fio -y
# 4K随机写测试，持续60秒
fio --name=randwrite --ioengine=libaio --rw=randwrite --bs=4k --size=1G --numjobs=4 --iodepth=16 --runtime=60 --time_based --direct=1 --group_reportingFocus on the distribution of lat (usec) and iops. If the latency curve shows severe jitter, it indicates that the physical disk performance is extremely unstable when cache misses occur.
Cliff Detection Method
Perform multiple small-file read/write tests consecutively, recording the IOPS or throughput each time. For example:
for i in {1..10}; do
dd if=/dev/zero of=testfile bs=1M count=64 oflag=direct 2>&1 | tail -1
rm testfile
doneIf the speed suddenly drops from hundreds of MB/s to tens of MB/s, and this happens frequently, it can be diagnosed as a disk cache cliff.
Other Auxiliary Detection Methods
1. Memory Availability
Overselling can also occur with memory. Use free -h to observe available memory. If it frequently falls below 10% and swap usage is significant, it indicates that memory is also oversold.
2. Neighbor Concurrency Test
Attempt to perform stress testing during specific time periods (e.g., evening peak hours) and compare the Steal Time with that of idle periods. If the metrics deteriorate significantly during peak hours, it further corroborates overselling.
3. Long-term Monitoring
It is recommended to use sar or atop to continuously record system metrics for at least one week. Pay attention to performance fluctuations at fixed times each week.
# Use sar to record CPU history (requires sysstat installed)
sar -u 60 > /tmp/cpu_history.log &How to deal with overselling?
- Avoid peak times: For non-real-time businesses, schedule tasks to off-peak hours.
- Add caching: Use caches like Redis at the application layer to reduce dependence on underlying disk I/O.
- Switch providers: If Steal Time remains consistently high, decisively migrate to cloud providers that do not oversell or have a low overselling ratio.
- Choose high-performance plans: Some providers offer VPS with “dedicated CPU” or “limited overselling,” which cost more but offer more stable performance.
We recommend using professional detection tools for evaluation before purchasing. You can get automated detection scripts on the Detection Instructions page to generate a detailed overselling detection report with one click.
Conclusion
VPS overselling detection is not a one-time operation; it requires continuous monitoring. By using the two core metrics of Steal Time and disk Cache cliff, combined with stress testing and long-term recording, you can effectively determine whether the current VPS is excessively oversold, and thus make a decision on whether to upgrade or migrate.
Remember, no single metric can 100% confirm overselling, but combining data from multiple dimensions is enough to see the truth.
Hopefully this practical guide can help you avoid detours when choosing a VPS. If you are considering switching providers, it is recommended to test your current server using the methods in this article first, and then compare the test results with the target provider.