The Lie Behind "Guaranteed" RAM
If I see one more hosting provider selling "burstable RAM" as a feature, I'm going to pull a cable. It is 2009. We are building complex LAMP stacks and high-concurrency Ruby on Rails applications. We cannot rely on the charity of a shared kernel scheduler.
Here is the reality for most of you running on standard VPS platforms today: you are likely on OpenVZ or Virtuozzo. It’s efficient for the host, sure. But when your neighbor's poorly optimized WordPress loop goes rogue, your database latency spikes. Why? Because you are sharing the OS kernel.
At CoolVDS, we have moved strictly to KVM (Kernel-based Virtual Machine) for all production tiers. With the recent maturity of the Linux 2.6.20+ kernel, KVM is no longer just a Red Hat experiment—it is the only way to guarantee that your resources are actually yours.
The Architecture: Ring -1
To understand why your MySQL queries are hanging, you need to look at the CPU flags. OpenVZ runs containers on top of a single OS. It's software emulation. KVM, utilizing Intel VT-x or AMD-V extensions, pushes the hypervisor into the hardware.
Run this command on your current server:
grep -E 'svm|vmx' /proc/cpuinfo
If you don't see output, or if you cannot load your own kernel modules, you are trapped in a container. You cannot tune your TCP stack properly, and you certainly cannot run a custom kernel for specific security patches.
Pro Tip: Using KVM allows us to expose raw block devices to the guest. This reduces I/O overhead significantly compared to the file-system-in-a-file approach used by older Xen loops.
War Story: The Magento "Black Friday" Meltdown
Last month, we migrated a client running a heavy Magento installation (1.3.x). They were hosting on a "high performance" container platform in Germany. Every evening at 20:00, their load average jumped from 0.5 to 15.0.
We checked the slow query log. Nothing. We checked Apache logs. Normal traffic. The issue wasn't their code; it was a "noisy neighbor" on the same physical host processing video files, stealing CPU cycles that the hypervisor failed to ring-fence.
We moved them to a CoolVDS KVM instance running CentOS 5.3. We allocated dedicated cores. The result? Flatline stability. The site load dropped to 0.2 and stayed there.
Optimizing for KVM in 2009
If you are switching to a KVM-based VPS, you need to treat it like bare metal. This means you must tune your I/O scheduler. The default Linux scheduler, CFQ (Completely Fair Queuing), is designed for rotating physical platters, attempting to minimize head seek time.
However, inside a VM, the host handles the physical disk. Your guest OS shouldn't try to outsmart the host. Switch your scheduler to deadline or noop to lower CPU overhead:
echo noop > /sys/block/sda/queue/scheduler
Add this to your /etc/rc.local to make it permanent. This simple change can reduce I/O latency by 10-15% on virtualized workloads.
The Storage Bottleneck: SAS vs. SSD
While 15k RPM SAS drives in RAID-10 are the industry standard for reliability, we are beginning to see the first generation of Enterprise SSDs (like the Intel X25-E) change the game for database hosting. While expensive, the IOPS throughput is shattering benchmarks.
At CoolVDS, we are rolling out SSD caching tiers. For a database heavy application, seek time is the enemy. Standard spinning disks have a seek time of ~3ms. SSDs are practically zero. If your dataset fits in RAM, great. If not, you need faster storage, not just more CPU.
Data Sovereignty: Why Norway?
Beyond the technical specs, we have to talk about the Datatilsynet (Data Inspectorate). With the strict enforcement of the Personopplysningsloven (Personal Data Act of 2000), storing data outside of Norway is becoming a compliance headache for local businesses.
Hosting in the US or even cheaper hubs in Eastern Europe introduces legal latency. Our servers are located in Oslo, peering directly at NIX (Norwegian Internet Exchange). This keeps your pings to local ISPs (Telenor, NextGenTel) under 5ms.
| Feature | Container (OpenVZ/Virtuozzo) | CoolVDS (KVM) |
|---|---|---|
| Kernel | Shared (Cannot modify) | Dedicated (Customizable) |
| Memory | Burstable (Unreliable) | Dedicated (Hard Limit) |
| Isolation | Process Level | Hardware Level (SELinux friendly) |
| Swap | Often Fake/None | Real Partition |
Final Thoughts
Virtualization is not just about slicing up a server; it's about predictable performance. If you are serious about uptime, you cannot afford to share your kernel space. The industry is moving toward hardware-assisted virtualization. By 2010, I predict container-based hosting will be relegated to the bargain bin.
Don't let your infrastructure be the bottleneck. Deploy a true KVM instance on CoolVDS today, configure your own kernel, and see what your application can actually do.