The Truth About Server Resources (And Why 'Burst' RAM is a Lie)

It is 3:00 AM. Your monitoring system—maybe Nagios, maybe a frantic client email—wakes you up. The load average on your server is soaring past 20.0, but your traffic graphs are flat. You log in via SSH, latency makes the cursor lag by half a second, and you run top.

There it is. High %wa (iowait) and the dreaded %st (steal time).

If you are hosting on budget commodity hardware, you aren't fighting your code; you are fighting your neighbors. In the Norwegian hosting market, where we pride ourselves on stability and the robustness of the NIX (Norwegian Internet Exchange), this is unacceptable. Let’s strip away the marketing fluff and look at what you are actually paying for when you buy a VPS.

1. CPU: Cycles vs. Steal Time

Most providers oversell CPU cores. They rely on the fact that not every customer uses 100% of their processor all the time. But when you are running a high-traffic Magento store or a heavy Drupal site, you need those cycles now.

In a virtualized environment, the hypervisor schedules CPU time for each guest. If your provider has crammed too many virtual machines onto one physical Xeon 5500 server, the hypervisor forces your machine to wait while another customer processes a batch job.

The Metric to Watch: Run top and look at the %st value.

Cpu(s): 12.5%us,  2.0%sy,  0.0%ni, 55.0%id, 10.2%wa,  0.0%hi,  0.1%si, 20.2%st

If %st (Steal Time) is consistently above 0%, your provider is shortchanging you. You are paying for a 2.4GHz core but getting the performance of a Pentium III. At CoolVDS, we strictly limit tenant density per node to ensure %st stays at zero.

2. RAM: Guaranteed vs. Burst

Be extremely wary of "Burst RAM." This is common terminology in OpenVZ hosting. They might sell you "512MB Guaranteed, 1GB Burst."

Here is the reality: You only have 512MB.

The "burst" memory is only available if the host node has free RAM. If a neighbor decides to compile a kernel or run a backup script, that burst memory vanishes instantly. If your MySQL process was using it, the OOM (Out of Memory) killer wakes up and terminates your database. Crash. Downtime.

Pro Tip: Always size your production applications based on guaranteed RAM only. Better yet, use Xen virtualization (which CoolVDS uses standard) where memory is hard-allocated to your kernel. It cannot be stolen.

3. Storage: The I/O Bottleneck

In 2009, disk I/O is the single biggest performance killer. Processors have become incredibly fast, but mechanical hard drives haven't kept up.

Many hosts put you on a single SATA drive or a cheap RAID 1 setup. If another user on the same physical disk starts a heavy file transfer, your database queries will hang. This shows up as %wa (Wait I/O) in your stats.

The Solution: Enterprise RAID 10

You should accept nothing less than RAID 10 with high-speed SAS drives (15,000 RPM). RAID 10 strips data across multiple disks for speed and mirrors it for redundancy. While early SSDs (Solid State Drives) like the Intel X25-E are starting to appear in enterprise labs, they are still prohibitively expensive for mass hosting. Until SSDs become standard, a battery-backed RAID 10 SAS array is the king of throughput.

Real-World Optimization: The MySQL Config

Having dedicated resources means nothing if your software isn't tuned to use them. A default my.cnf in CentOS 5 is optimized for a server with 64MB of RAM. It's tragic.

If you are on a CoolVDS 1GB dedicated plan, you must adjust your InnoDB buffer pool. Since we provide dedicated RAM, you can safely allocate 60-70% of it to the database if the server is a dedicated DB node.

[mysqld]
# Optimize for 1GB RAM Dedicated Node
innodb_buffer_pool_size = 512M
innodb_log_file_size = 128M
innodb_flush_log_at_trx_commit = 2 # Trade slight ACID compliance for massive speed
query_cache_size = 32M

The Privacy Angle: Norway vs. The World

Beyond raw specs, location matters. Hosting inside Norway ensures your data stays within the jurisdiction of the Datatilsynet. With the increasing scrutiny on data privacy in Europe, keeping your customer data on local soil reduces legal headaches significantly compared to US-based safe harbor relying providers.

Furthermore, if your audience is in Oslo, Bergen, or Trondheim, latency matters. Pinging a server in Texas takes ~140ms. Pinging a CoolVDS server in Oslo takes ~15ms. That speed difference is immediately noticeable to your end-users.

Final Verdict

You cannot optimize your way out of bad hardware. If your current host suffers from high Steal Time or I/O Wait, no amount of caching will save you.

Stop fighting your neighbors for resources. Deploy a Xen-based, RAID-10 accelerated instance on CoolVDS today and get the dedicated performance you are actually paying for.