In today's computers, CPU throughput and amount of memory are no longer the bottleneck in performance. Ask any server administrator and they will tell you that one of the biggest concerns with responsiveness of server-side applications is the throughput to and from disk. If you're using the ext3 filesystem, it turns out there's a tip that you can use to gain up to a 40% performance boost.
With the default mount options in most distributions, the filesystem will log the last access time to a file. Hackosis recently wrote a quick tutorial on how to disable the access logging in the /etc/fstab file. A little research shows reveals a conversation in 2007 between kernel developers such as Linus Torvalds and Ingo Molnar in which Ingo states his experience with changing the setting:
yeah, it's really ugly. But otherwise i've got no real complaint about
ext3 - with the obligatory qualification that "noatime,nodiratime" in
/etc/fstab is a must. This speeds up things very visibly - especially
when lots of files are accessed. It's kind of weird that every Linux
desktop and server is hurt by a noticeable IO performance slowdown due
to the constant atime updates, while there's just two real users of it:
tmpwatch [which can be configured to use ctime so it's not a big issue]
and some backup tools. (Ok, and mail-notify too i guess.) Out of tens of
thousands of applications. So for most file workloads we give Windows a
20%-30% performance edge, for almost nothing. (for RAM-starved kernel
builds the performance difference between atime and noatime+nodiratime
setups is more on the order of 40%)
Using the Hackosis' tip on disabling the access logging could help boost performance on any systems you have using ext3. Of course, I'd recommend trying it out in a test system before deploying it in a production system, especially since changing the options means you have to re-mount your filesystems. I usually use ReiserFS, but if you are using something like Red Hat or CentOS, the kernel builds don't support the xfs, jfs, or reiser filesystems unless you compile the options in yourself. Granted, you have to have a "RAM-starved" system first as Ingo states, but if you are experiencing performance issues on a server, there's a good chance it's a RAM-starved system or low I/O throughput.