Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a brand new server w/48G RAM which I am going to use as a DB server. I don't expect problems with disk reads, but I definitely would like to optimize for write intensive load patterns.

The OS is RHEL 5.6 and the FS is ext3, I've added "noatime" and "data=writeback" to /etc/fstab already and the latter option helped to reduce LA a lot. My next goal is to optimize the pdflush process wherever possible. I tried to apply tweaks mentioned here, but to no avail. Probably this information is just outdated.

What are my further options? Should I continue experimenting with pdflush or maybe it's better just to leave it as is? I tend to lower dirty_ratio and dirty_background_ratio sysctl values to increase I/O smoothness but these values seem to be not related to performance, the load pattern in Munin under stress test is basically the same.

Should I also try different I/O scheduler? Can I benefit from having lots of RAM in a write intensive setup at all? I understand that disk I/O speed and latency are nothing to do with the RAM, but my goal is not to magically write to disk faster, but to increase system stability and to implement some kind of graceful degradation.

Let's say I have good backups and can accept further data consistency tradeoffs like "data=writeback".
Thank you.

share|improve this question
up vote 4 down vote accepted

Is ext3 a requirement? You have the XFS filesystem as an option, which may work better for your workload. What is the underlying storage setup? What are your measured results compared to the storage system's capabilities (e.g. have you identified the bottleneck?)? Try the other I/O scheduler elevator settings. I prefer noop for certain direct-attached storage arrays and deadline for others. Test and measure for your particular application.

share|improve this answer
+1. For a DB server deadline is typically a way better choice than the default CFQ scheduler. Or, if you have some fancy hardware, noop can be good choice too. – Janne Pikkarainen Jun 8 '11 at 10:07
Thank you guys, I am going to run MySQL-specific benchmarks with different I/O scheduling options. – Alex Jun 8 '11 at 11:15

What is your disk setup like? If you're using a hardware RAID array, you can set the stride and stripe-width options for optimal file system alignment.

Additionally, if you have a battery backed caching controller you can set the nobarrier option at mount.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.