database

Drupal scalability, Part 2

This is a follow up to a writeup I did last year. Read the previous article about Drupal scalability for the back story. In five months nearly nothing has changed in the production environment at work. What has changed is my understanding of disk performance, as it relates to databases, and the power of higher level caching.

I couple months ago I spent many hours looking at disk stats in Linux with the iostat utility. How many writes per second can a three disk RAID 5 array do?

How many disks does it take to screw in a database?

My previous experience with optimizing disk performance in Linux revolved around getting huge chunks of data off disk quickly, but this means nothing to a typical database. Databases are usually limited by how many IOPS (Input/Output Operations Per Second) the disk subsystem can sustain. The database servers at work have plenty of RAM so disk reads nearly always come from the disk cache and disk writes appear to be our bottleneck.

The database servers each have a RAID 5 array with three 10k RPM drives, while the web servers each have mirrored 15k RPM drives. all SAS.

Drupal scalability

The company I work for currently runs numerous Drupal websites, which are now beginning to experience performance issues. The hardware in the production environment "seems" adequate, but nobody really knows what the problem is or how to address it. The camel's straw, as far as acceptable performance, seems to be the last website we put into production, which shares this same server infrastructure.