The "Burst RAM" Myth is Killing Your Database Performance

Let’s be honest about the state of the VPS market in 2010. If you are running a MySQL database on a standard budget VPS, you are likely sitting on an OpenVZ or Virtuozzo container. You see 4GB of RAM in top, but the moment your InnoDB buffer pool tries to use it, the host kernel kills your process. Why? because that RAM never really belonged to you.

We are seeing a massive shift in the Linux ecosystem right now. Just last month, Red Hat Enterprise Linux 6 was released, and they made a bold move: they deprecated Xen in favor of KVM (Kernel-based Virtual Machine). If the engineers at Red Hat are betting their enterprise future on KVM, we need to pay attention.

The Architecture of Isolation

The problem with container-based virtualization (like OpenVZ) is that you share the host's kernel. You cannot load your own kernel modules. You cannot tune standard TCP congestion control algorithms like cubic or reno effectively if the host forbids it. Worse, you are at the mercy of the "noisy neighbor" effect.

KVM is different. It turns the Linux kernel into a hypervisor. Each guest has its own kernel, its own memory space, and most importantly, true hardware virtualization instructions (Intel VT-x or AMD-V). This means when you buy a KVM slice, you are getting dedicated resources, not a promise of "burstable" resources.

Pro Tip: To verify if your CPU supports hardware virtualization required for KVM, run this on your host:
egrep -c '(vmx|svm)' /proc/cpuinfo
If it returns 0, you're stuck in the dark ages.

Tuning KVM for High-Load Production

At CoolVDS, we have moved our entire infrastructure to KVM on CentOS 5.5 and the new RHEL 6 stack. We did this because our clients running Magento and high-traffic vBulletin forums were tired of I/O wait spikes caused by other users.

Here is a battle-tested configuration for maximizing disk I/O performance inside a KVM guest. The default I/O scheduler in Linux is often set to cfq (Completely Fair Queuing), which is great for desktops but terrible for virtualized servers where the hypervisor is already handling scheduling.

Switch your elevator to deadline or noop inside the guest VM to lower latency:

Verify it with:

The Storage Bottleneck: SAS vs. SSD

We are currently witnessing the early adoption of Solid State Drives (SSDs) in the enterprise. While 15k RPM SAS drives in RAID-10 have been the gold standard for years, the random read/write speeds of Intel's X25-series SSDs are changing the game for database hosting. If you can afford the premium, SSD storage eliminates the seek time latency that kills MySQL performance.

However, for most massive storage needs, a good RAID-10 SAS setup still offers the best balance of reliability and speed. Just ensure your provider isn't putting 500 VMs on a single array.

Norwegian Data Sovereignty (Datatilsynet Compliance)

Latency isn't the only reason to host locally. With the growing concerns around the US Patriot Act and the stability of the Safe Harbor agreement, keeping data inside Norway is becoming a critical requirement for CTOs.

Under the Personopplysningsloven (Personal Data Act), you are responsible for where your customer data physically resides. Hosting in a datacenter in Oslo connected directly to NIX (Norwegian Internet Exchange) ensures two things:

1. Compliance: You satisfy Datatilsynet's strict requirements for handling sensitive personal data.
2. Speed: You get sub-5ms pings to almost anywhere in Norway.

Why We Chose KVM for CoolVDS

We didn't just pick KVM because it's the shiny new toy in kernel 2.6.20+. We picked it because it respects the sysadmin. When you run uptime on a CoolVDS KVM instance, the load average is real. When you allocate 4GB of RAM, it’s yours.

If you are tired of your mysqld process crashing because a neighbor on your node decided to compile a kernel, it’s time to upgrade. True virtualization is the only path forward for serious production workloads.

Ready to test the difference? Spin up a KVM instance on our Oslo-based infrastructure today. Don't let disk I/O kill your uptime.