Console Login
Home / Blog / Server Administration / KVM vs. OpenVZ: Why Shared Kernels Are Killing Your Production Database
Server Administration 0 views

KVM vs. OpenVZ: Why Shared Kernels Are Killing Your Production Database

@

The Myth of "Burstable RAM": Why Serious Admins Choose KVM

It is 3:00 AM. Your pager is buzzing. Your MySQL service just died again, but your monitoring shows plenty of free RAM. You check the logs, scratch your head, and restart the service. Twenty minutes later, it happens again.

If you are hosting on a budget VPS provider using OpenVZ, you aren't fighting a memory leak in your code. You are fighting your neighbors.

In the current hosting landscape of 2009, overselling is the industry's dirty secret. Most providers pile hundreds of containers onto a single node, betting that not everyone will use their CPU cycles at once. But when you are running a high-load Magento store or a critical PostgreSQL cluster, "averages" don't matter. Latency does. Reliability does.

The /proc/user_beancounters Lie

If you are on an OpenVZ system (or Virtuozzo), run this command right now:

cat /proc/user_beancounters

See that failcnt column? If it's anything other than zero, your processes are being killed by the host node, regardless of what top tells you about your available memory. This is because OpenVZ shares a single Linux kernel across all instances. When the host runs out of Low Memory, it starts killing processes in the containers, even if you are well within your "guaranteed" limit.

This architecture was fine for static HTML sites in 2005. For dynamic Web 2.0 applications in 2009? It is negligence.

Enter KVM: True Hardware Virtualization

At CoolVDS, we have standardized on KVM (Kernel-based Virtual Machine). Since being merged into the Linux kernel (2.6.20), KVM has changed the game. Unlike container-based virtualization, KVM turns the Linux kernel into a hypervisor.

What does this mean for your uptime?

  • Full Kernel Isolation: You run your own kernel. You can load your own modules (modprobe actually works). If a neighbor on the host node panics their kernel, your instance keeps humming.
  • Real Memory Allocation: When we assign 2GB of RAM to a CoolVDS KVM instance, that RAM is reserved at the hardware level. No "burst" marketing fluff. It is yours.
  • Custom Tuning: Need to change TCP congestion control algorithms or tweak sysctl.conf parameters that are usually locked on shared kernels? On KVM, you have root access to the metal.

Optimizing for I/O: The Bottleneck is the Disk

CPU cycles are cheap. Disk I/O is where servers die. In a shared environment, one user compiling a massive C++ project can trash the disk queue for everyone else.

While standard SAS 15k RPM drives in RAID-10 are the industry standard for enterprise reliability, we are seeing massive performance gains with the new generation of Enterprise SSDs (like the Intel X25 series). The seek times are practically nonexistent compared to spinning platters.

However, even on standard storage, KVM allows better I/O scheduling. We recommend using the deadline or noop scheduler inside your guest VM for database workloads, rather than the default cfq.

Pro Tip: Check your scheduler setting.
cat /sys/block/sda/queue/scheduler
If you are running a heavy database, switch it:
echo deadline > /sys/block/sda/queue/scheduler

The Norwegian Advantage: Latency and Law

Performance isn't just about disk speed; it's about network physics. If your primary user base is in Scandinavia, hosting in Germany or the US adds unnecessary milliseconds. CoolVDS infrastructure is peered directly at NIX (Norwegian Internet Exchange) in Oslo.

Furthermore, we must respect the Personal Data Act (Personopplysningsloven). Keeping your data within Norwegian borders satisfies the stringent requirements of the Data Inspectorate (Datatilsynet). With the legal landscape shifting, relying on Safe Harbor agreements for US hosting is a risk a pragmatic CTO shouldn't take.

Configuration for Stability

Moving to KVM allows you to run a properly tuned LAMP stack. Here is a snippet from a standard my.cnf we use for 4GB RAM instances to prevent swapping:

[mysqld] innodb_buffer_pool_size = 2G innodb_flush_log_at_trx_commit = 2 query_cache_size = 64M skip-external-locking

On a shared kernel container, these settings might still result in OOM (Out of Memory) kills because the host overcommitted. On a CoolVDS KVM instance, this configuration runs rock solid.

Final Thoughts

You can save $5 a month on a cheap container, or you can sleep through the night knowing your kernel belongs to you. If your project has moved beyond a hobby, the choice is clear.

Ready to stop fighting for resources? Deploy a KVM instance on CoolVDS today and get root access in under 55 seconds.

/// TAGS

/// RELATED POSTS

Surviving the Spike: High-Performance E-commerce Hosting Architecture for 2012

Is your Magento store ready for the holiday rush? We break down the Nginx, Varnish, and SSD tuning s...

Read More →

Automate or Die: Bulletproof Remote Backups with Rsync on CentOS 6

RAID is not a backup. Don't let a typo destroy your database. Learn how to set up automated, increme...

Read More →

Xen vs. KVM: Why Kernel Integration Wars Define Your VPS Performance

Red Hat Enterprise Linux 6 has shifted the battlefield from Xen to KVM. We analyze the kernel-level ...

Read More →

Escaping the Shared Hosting Trap: A SysAdmin’s Guide to VDS Migration

Is your application choking on 'unlimited' shared hosting? We break down the technical migration to ...

Read More →

IPTables Survival Guide: Locking Down Your Linux VPS in a Hostile Network

Stop script kiddies and botnets cold. We dive deep into stateful packet inspection, fail2ban configu...

Read More →

Sleep Soundly: The Paranoid SysAdmin's Guide to Bulletproof Server Backups

RAID is not a backup. If you accidentally drop a database table at 3 AM, mirroring just replicates t...

Read More →
← Back to All Posts