Console Login

The I/O Bottleneck: Why Your 'Cloud' Storage is Killing Application Performance

The I/O Bottleneck: Why Your "Cloud" Storage is Killing Application Performance

It is 2010, and the buzzword of the year is "Cloud." Everyone from Amazon to Rackspace is promising infinite scalability. But as systems administrators, we know the dirty secret that marketing brochures ignore: Disk I/O is the single biggest bottleneck in virtualized environments.

I recently audited a Magento installation for a client in Oslo. They were running on a budget US-based VPS provider. The CPU load was low, RAM was plentiful, yet the checkout process took eight seconds. The culprit? I/O Wait. Their database was fighting for disk access with five hundred other virtual machines on a choked Storage Area Network (SAN). If you care about performance, you need to stop looking at gigahertz and start looking at IOPS (Input/Output Operations Per Second).

The Architecture of Slowness: SAN vs. Local Storage

Most "cloud" providers today use massive SAN arrays connected via Fibre Channel or iSCSI. It sounds enterprise-grade, but when 2,000 users hit that storage simultaneously, latency spikes. For a database like MySQL, which relies heavily on random writes, network-attached storage can be a death sentence unless the network fabric is pristine.

At CoolVDS, we take a different approach: Local RAID-10 Hardware Storage. By keeping the data on the physical chassis where the computation happens, we eliminate network latency entirely. We use 15k RPM SAS drives (and are currently testing early Enterprise SSDs for caching tiers) to ensure that when your application writes to disk, it happens instantly.

Pro Tip: Check your current bottleneck. Run iostat -x 1 on your Linux box. If %util is near 100% while CPU is idle, your storage is choking your business.

The "Noisy Neighbor" Problem in 2010

Virtualization technology like OpenVZ allows overselling. A provider can cram 50 customers onto a node designed for 20. If one neighbor decides to compile a kernel or run a backup script, your disk performance tanks. This is why isolation matters.

We prefer Xen HVM or the emerging KVM technology. These hypervisors provide stricter isolation. But software limits aren't enough. You need hardware that can handle the throughput. This is why we configure our RAID controllers with battery-backed write caches (BBWC). This allows the controller to acknowledge the write immediately before flushing it to the physical disk, smoothing out bursty traffic.

Optimizing Your Filesystem for Speed

If you are stuck on a legacy provider, or setting up your own CoolVDS instance, default settings in CentOS 5 or Debian Lenny are often too conservative. Here is a quick win for your /etc/fstab.

By default, Linux updates the "access time" (atime) every time a file is read. For a high-traffic web server reading thousands of PHP files and images, this generates unnecessary write traffic. Turn it off.

/dev/sda1 /var/www ext3 defaults,noatime,nodiratime,data=writeback 1 2

Note: Only use data=writeback if you have a battery-backed RAID controller, like we do at CoolVDS, otherwise you risk file corruption during a power loss.

Data Sovereignty: The Norwegian Context

Performance isn't the only concern. The Norwegian Personal Data Act (Personopplysningsloven) and the watchful eye of Datatilsynet mean you cannot simply throw sensitive customer data onto a server in Texas and hope for the best. The Safe Harbor framework exists, but legal interpretations are tightening.

Hosting within Norway isn't just about lower latency to the NIX (Norwegian Internet Exchange) in Oslo—though shaving 30ms off your ping is fantastic for user experience. It is about knowing exactly where your physical bits reside. CoolVDS operates out of top-tier datacenters right here in Oslo, ensuring your data falls strictly under Norwegian jurisdiction.

Conclusion

Don't be seduced by "unlimited cloud storage" offers. If the I/O throughput isn't there, your site will feel sluggish, Google bots will crawl you slower, and your customers will bounce. You need dedicated spindles (or SSDs), reliable RAID-10, and a network that keeps your data close to your users.

Ready to stop waiting on your hard drive? Deploy a high-performance Xen instance on CoolVDS today and see what local RAID-10 does for your MySQL queries.