Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a high-IO application that is working, and scaling well to date. Over the past few months we've been trying to look down the road and predict where our next bottlenecks will occur. One of them is surly the file system.

We are currently monitoring

  • Space available
  • Read operations per second
  • Write operations per second

This seems a bit too sparse to me--What else should I be watching? And I am not even sure what the 'yellow line' would be for the operations/second. Suggestions?

share|improve this question

1 Answer 1

up vote 3 down vote accepted

Some suggestions

  • Look at the read queue size, if your application is highly random, then tweak the readahead in /sys/block/<< dev >>/queue/read_ahead_kb to ensure your reading data you need not data the os thinks you need.
  • Switch to the deadline scheduler if you haven't already
  • use the noatime mount option unless you're hosting a mail spool
  • mount with data="writeback" if you've got good backups
  • keep an eye on your directory sizes, sure hashed directory inodes help, but if you can hash the data yourself then you'll get more consistent results
share|improve this answer
    
Our directory structure is pretty well hashed as is, but will look again. What would you suggest as "too big" or "too many files" for a directory? –  Stu Thompson Apr 30 '09 at 11:02
2  
Take a look at how squid hashes their proxy store. They've got some good documentation on choosing a hashing depth and the tradeoffs –  Dave Cheney Apr 30 '09 at 11:08
1  
I agree with noatime but I can't really recommend setting the FS to writeback mode. –  BobbyShaftoe May 1 '09 at 11:03

Your Answer

 
discard

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.