Console Login
Home / Blog / Server Optimization / Stop Watching 'wa' in Top: Why Spinning Disks Are the Bottleneck in 2011
Server Optimization 1 views

Stop Watching 'wa' in Top: Why Spinning Disks Are the Bottleneck in 2011

@

The Spinning Disk Bottleneck: Why Your 15k RPM Drives Are Obsolete

It is 3:00 AM. Your pager goes off. You SSH into your primary database server, run top, and see the dreaded sight: CPU usage is low, RAM is free, but load average is sky-high. And there it is, staring you in the face: %wa (I/O wait) is hovering at 40%.

Your server isn't processing data. It's waiting for a mechanical arm to physically move a magnetic head across a spinning platter. In an era where we optimize code down to the millisecond, relying on mechanical physics for data retrieval is insanity. At CoolVDS, we believe the era of the spinning disk for primary hosting is over.

The IOPS Lie: SAS vs. SSD

Many hosting providers in Norway are still pushing "Enterprise SAS" arrays as the gold standard. They tout 15,000 RPM speeds. While reliable, the physics simply doesn't add up for modern, database-heavy applications like Magento or Drupal.

Let's look at the raw numbers for Random 4K Read/Writes (the traffic pattern of a busy MySQL server):

Drive Type Avg IOPS (Random 4K) Latency
7.2k RPM SATA ~75-100 12ms+
15k RPM SAS ~175-210 5-8ms
CoolVDS Enterprise SSD 20,000+ < 0.1ms

A single SSD outperforms an entire rack of 15k SAS drives in RAID 10. When your database receives hundreds of concurrent requests, the SAS drive queue depth explodes. The SSD just blinks and asks for more.

War Story: The Magento Meltdown

We recently migrated a client running a high-traffic e-commerce store targeting the Nordic market. They were hosted on a "premium" VPS with a competitor in Oslo, running on a SAN with mechanical drives. During a flash sale, their checkout page took 8 seconds to load.

We ran iostat -x 1 during the peak:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           12.40    0.00    3.50   82.10    0.00    2.00

Device:         rrqm/s   wrqm/s     r/s     w/s   svctm   %util
sda               0.00     5.00  150.00   80.00    4.30   98.50

The disk utilization was pinned at 98.5%. The CPU was bored. The database was locked waiting for writes to commit.

We moved them to a CoolVDS SSD instance. Without changing a single line of PHP code, page load times dropped to 0.8 seconds. The I/O wait vanished.

Configuring MySQL 5.5 for SSD

Simply moving to SSD isn't enough; you must tell your software that it no longer needs to be gentle with the disk. Most default my.cnf configurations assume you are running on slow, spinning rust.

If you are on a CoolVDS SSD plan, you need to adjust the InnoDB I/O capacity. The default is often set to 200, which artificially throttles the database to match an old hard drive's speed.

Update your /etc/my.cnf:

[mysqld]
# Default is 200. Crank this up for SSD.
innodb_io_capacity = 2000

# Disable the "doublewrite" buffer if you trust your filesystem (check ZFS/ext4 stability)
# innodb_doublewrite = 0 

# Ensure flush method is set correctly for Linux
innodb_flush_method = O_DIRECT
Pro Tip: Don't just guess. Use the mysqlslap utility to benchmark your changes before and after hitting the config file.

The Latency Factor: Oslo to the World

Speed isn't just about disk I/O; it's about network latency. If your target audience is in Norway, hosting in Germany or the US adds 30-100ms of unavoidable latency due to the speed of light.

CoolVDS infrastructure is peered directly at NIX (Norwegian Internet Exchange) in Oslo. Combined with our SSD storage, this ensures the "Time to First Byte" (TTFB) is virtually instantaneous for local users.

Data Integrity and Norwegian Law

Beyond performance, keeping data on Norwegian soil simplifies compliance with the Personopplysningsloven (Personal Data Act) and satisfies the Datatilsynet requirements. You know exactly where your physical bytes are stored—on fast flash memory in Oslo, not scattered across a murky cloud.

Conclusion

In 2011, continuing to host database-driven applications on mechanical hard drives is a choice to accept mediocrity. The bottleneck has shifted. It is no longer the CPU or the RAM; it is the storage.

If you are tired of debugging high load averages and sluggish queries, the solution might not be code optimization. It might just be better hardware.

Ready to eliminate I/O wait? Deploy a CoolVDS SSD instance today and see the difference flash storage makes.

/// TAGS

/// RELATED POSTS

Stop Waiting on I/O: Supercharging LAMP Stacks with Redis 2.2

Disk latency is the silent killer of web applications. We benchmark Redis vs Memcached, explore the ...

Read More →

WordPress 3.0 Optimization: Architecting for Speed in a Post-LAMP World

WordPress 3.0 "Thelonious" has just dropped. It merges MU and brings custom post types, but it deman...

Read More →

Why Shared Hosting is Suffocating Your PHP Apps (And How to Scale in 2009)

Stop battling 'noisy neighbors' and Apache overhead. Learn how to optimize PHP 5.3, tune MySQL buffe...

Read More →

Escaping the Apache Bloat: Tuning PHP Performance with PHP-FPM and Nginx

Is mod_php eating your RAM? Learn how to implement the PHP-FPM patch with Nginx to handle high concu...

Read More →

Stop the Swap: Accelerating High-Load Web Apps with PHP-FPM in 2009

Is Apache mod_php eating your RAM? Discover how switching to PHP-FPM and Nginx can handle high concu...

Read More →

VPS Resources Explained: Why CPU 'Steal Time' and I/O Wait Are Killing Your App

Is your 'guaranteed' RAM actually available? We break down CPU scheduling, disk I/O bottlenecks (RAI...

Read More →
← Back to All Posts