Stop Letting 'Noisy Neighbors' Steal Your CPU Cycles
It is 3:00 AM. Your monitoring system—Nagios, if you are sensible—is screaming. Your Magento 1.4 store just went down. Again. You log in via SSH, run top, and see... nothing. Your load average is 0.2. Your RAM usage is fine. Yet, Apache is hanging.
Welcome to the hell of container-based virtualization (OpenVZ/Virtuozzo). In these environments, you are sharing the host kernel with fifty other customers. If one of them decides to compile a massive kernel or gets hit by a DDoS, you pay the price in stolen CPU cycles and I/O wait.
In 2011, serious systems architects are moving away from the "overselling" model of containers and embracing KVM (Kernel-based Virtual Machine). At CoolVDS, we made the architectural decision early: we do not gamble with your stability. We use KVM.
The Architecture: Why KVM is 'Real' Virtualization
Many hosting providers in Norway push OpenVZ because it allows them to pack hundreds of users onto a single physical server. They sell you "Burst RAM"—memory that doesn't actually exist unless the server is idle. It is a gamble.
KVM is different. It has been part of the mainline Linux kernel since 2.6.20. When you provision a KVM instance, you are getting a dedicated slice of hardware resources. The operating system inside your VPS thinks it is on bare metal. It manages its own kernel, its own modules, and most importantly, its own memory allocation.
The 'Beancounters' Problem
If you have ever seen the error kmemsize: failcnt in your /proc/user_beancounters file, you know the pain. You might have free RAM displayed in free -m, but the hypervisor refuses to allocate it because you hit a hidden limit. KVM eliminates this entirely. If you pay for 4GB of RAM on a CoolVDS instance, that RAM is reserved for you. Period.
The Storage Revolution: Spinning Rust vs. SSD
The single biggest bottleneck in virtualization today is Disk I/O. Most hosts are still running RAID 10 arrays of SAS 15k RPM drives. They are reliable, sure, but when twenty virtual machines try to write to MySQL simultaneously, the read/write heads on those physical disks thrash wildly. Latency spikes.
This is why we are beginning to roll out Solid State Drive (SSD) storage tiers. The difference is not just incremental; it is exponential. While a standard SAS array might give you 300 IOPS (Input/Output Operations Per Second), enterprise SSDs can push thousands.
Pro Tip: If you are running MySQL 5.1 or 5.5 on Linux, the default I/O scheduler is usuallycfq. On a virtualized environment, especially with SSDs, this adds unnecessary overhead. Switch to thedeadlineornoopscheduler for better throughput.
Add this to your kernel parameters in Grub:
elevator=deadline
Local Latency and The "Datatilsynet" Factor
For those of us operating out of Norway, physical location matters. Routing traffic through Frankfurt or London adds 20-30ms of latency. That sounds negligible, but for a high-frequency trading bot or a heavy AJAX application, it adds up.
Hosting locally in Oslo means you are peering directly at NIX (Norwegian Internet Exchange). Your pings to local users drop to single digits. Furthermore, we must consider the legal landscape. The Data Protection Directive (95/46/EC) and Norway's Personopplysningsloven impose strict rules on where personal data can live. Keeping your data on servers physically located in Norway simplifies compliance with the Data Inspectorate (Datatilsynet) significantly compared to hosting in the US.
Configuration: Enabling VirtIO for Speed
Just switching to KVM isn't enough; you need to use paravirtualized drivers. By default, KVM might emulate a generic Realtek network card and an IDE hard drive. This is slow because the CPU has to emulate every hardware instruction.
To get near-native performance, you must ensure your provider (like CoolVDS) uses VirtIO drivers. This allows the guest OS to talk directly to the hypervisor.
Check if you are running VirtIO:
# grep -i virtio /boot/config-$(uname -r)
CONFIG_VIRTIO_BLK=m
CONFIG_VIRTIO_NET=m
If you see these modules, you are ready to fly. If you are stuck on emulated IDE drivers, you are leaving 30% of your disk performance on the table.
The Verdict
In 2011, you have a choice. You can stay on cheap, oversold container hosting and wonder why your site slows down every evening at 8:00 PM. Or, you can upgrade to a KVM-based architecture with dedicated resources and high-performance storage.
We built CoolVDS because we were tired of the "noisy neighbor" effect. We combine KVM isolation, emerging SSD technology, and direct connectivity to the Norwegian backbone to create a platform that respects your uptime.
Ready to stop sharing your CPU? Deploy a KVM instance with SSD storage on CoolVDS today and feel the difference.