Many people buy Hong Kong VPSs primarily for the benefits of "no registration required" and "international bandwidth." However, many experience the following: the speed is incredibly fast for the first week, but then it starts to lag, and even SSH commands become slow during peak hours (around 8 or 9 PM). This is likely due to CPU overprovisioning.

　　What exactly is overprovisioning?

　　Let's clarify this concept. Overprovisioning isn't a fault, but a resource management strategy. The logic is simple: a physical server has 16 physical cores, and theoretically, selling 8 "2-core" VPSs would be sufficient. However, the service provider gambles that these 8 users won't simultaneously max out the CPU. Therefore, they over-allocate resources on the physical machine, cramming in 20 or even 30 "2-core" VPSs.

　　Different virtualization solutions have vastly different tolerances for overprovisioning. Container-level virtualization like OpenVZ uses a "deduct-as-you-go" approach to resource allocation—reducing the amount deducted from the physical machine's memory based on actual usage. This design makes overselling virtually technically easy, and overselling rates easily exceeding 300% are not uncommon. Hardware-level full virtualization solutions like KVM and Xen offer much better resource isolation, resulting in a lower ceiling for overselling. Xen even uses a pre-allocation resource model, making significant physical overselling difficult.

　　The problem lies in the fierce competition in the Hong Kong VPS market. Many providers, even with KVM architecture, still push overselling ratios beyond the red line. The end result for users is that a machine labeled "4 cores" performs worse than a 1-core machine.

　　Typical manifestations of CPU overselling: From sensory experience to data

　　1. Performance fluctuates, especially noticeable during peak hours

　　This is the most easily perceived symptom. During the day, speed tests are normal, and pages load instantly; however, from 8 PM to 11 PM, website response slows significantly, and SSH operations experience noticeable latency. This kind of time-segmented lag is a strong signal of over-saturation—during peak hours, other users on the same physical machine are also heavily using the CPU, leading to concentrated resource contention.

　　If you observe this phenomenon, you can perform a simple quantitative comparison: run `sysbench cpu --cpu-max-prime=20000 run` during off-peak hours (e.g., 10 AM) and peak hours (e.g., 9 PM), and then compare the events per second values. If the difference exceeds 30% or even 50%, it can be basically determined that CPU resources are being severely shared.

　　2. High Steal Time

　　This is the most hardcore technical indicator for judging CPU over-saturation. Steal Time (%st) refers to how much time your vCPU is wasting while "waiting in the queue"—because the host machine allocates physical CPU time slices to other virtual machines, your processes can only wait.

　　You can see this value by executing `top` or `vmstat 1` on a Linux server. The industry typically uses 10% as a warning line: if Steal Time consistently exceeds 10% during peak business periods, it indicates severe contention for host machine resources; if it remains above 15% for an extended period, the physical machine is severely oversold and migration should be considered.

　　This value can be obtained more precisely using a single command:

grep "steal" /proc/stat | awk '{steal=$9; total=$2+$3+$4+$5+$6+$7+$8+$9; printf "Steal: %.2f%%\n", steal*100/total}'

　　3. Significant Discrepancy Between Nominal Configuration and Actual Performance

　　This is the most misleading aspect of overselling. The service charge may be labeled "4 cores," and the `lscpu` command will indeed show 4 CPUs. However, a stress test will expose the discrepancy.

　　Perform a full load test using a stress tool:

apt install stress -y   # Ubuntu/Debian
yum install stress -y   # CentOS

stress --cpu 4 --timeout 300s

　　Meanwhile, monitor CPU utilization using `top` on another terminal. If CPU utilization remains stable near 100%, resource allocation is considered healthy. If it remains low or fluctuates significantly between 20% and 80%, it indicates the scheduler is frequently switching between multiple vCPUs, often because vCPUs are mapped to the same physical core, or the host machine itself has a severely insufficient number of physical cores.

　　Memory also suffers.

　　When CPU overselling is severe, physical memory usage is usually not much better. Execute `free -m` to check Swap utilization. If Swap usage frequently exceeds 20% of physical memory when the system is idle, it indicates severe physical memory overselling, forcing data to be squeezed into the swap partition, where read/write speeds are much slower than memory. In this case, even if the CPU itself is fine, overall performance will be dragged down by the memory bottleneck.

　　The special characteristics of Hong Kong nodes: Bandwidth is also being shared.

　　CPU overselling in Hong Kong VPS often occurs simultaneously with bandwidth overselling. A package advertised as having 10M dedicated bandwidth may only have 2-3M in actual testing during peak hours. Test bandwidth using the following command:

wget -O /dev/null http://speedtest.tele2.net/100MB.zip

　　If a service is advertised as having 10Mbps dedicated bandwidth, the actual measured speed should be above 8Mbps. If it's less than half the advertised value, it indicates that the bandwidth is also oversold.

　　How to determine if you've been affected?

　　By combining the methods mentioned above into a simple detection process, you can quickly determine the issue within the first 48 hours after purchasing a new VPS:

　　1. During peak business hours (8-11 PM), run `vmstat 1 60` and observe the 1-minute average value of the steal column.

　　2. Run a full-load stress test to see if the CPU utilization can stably reach the advertised value.

　　3. Compare the benchmark scores between off-peak and peak times.

　　4. If steal > 5% or the benchmark score difference > 30%, you should seriously consider switching providers.

　　A few tips to avoid this pitfall:

　　1. First, consider the virtualization technology. OpenVZ architecture generally implies significant overselling; prioritize KVM or Xen solutions. However, even with KVM, pay attention to whether the provider explicitly states "dedicated CPU" or "no overselling." 2. Be wary of unusually low prices. Packages like "8 cores, 16GB RAM, 99 RMB per year" make it almost impossible for the service provider to profit without overselling. Industry observations show that over 67% of cheap VPSs have some degree of resource over-provisioning. Given the normal cost of Hong Kong CN2 lines, excessively low prices are suspicious.

　　3. Read the terms of service. If the SLA contains vague terms like "shared node resources," "burst performance," or "Up to," it indicates the service provider hasn't committed to a minimum resource guarantee. Providers that genuinely guarantee resource availability will usually clearly state "100% no overselling" and provide a specific resource allocation plan.

　　Finally, to be honest: mild overselling has a limited impact on personal blogs and test environments, given the price. However, if you're running a business with high stability requirements, spending a few extra dollars for an instance clearly marked as having "dedicated CPU" is far more worthwhile than being plagued by performance issues later.