7

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 surely 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? I am not even sure what the 'yellow line' would be for the operations/second.

1 Answer 1

4

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 you're 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
3
  • 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? Apr 30, 2009 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 Apr 30, 2009 at 11:08
  • 1
    I agree with noatime but I can't really recommend setting the FS to writeback mode. May 1, 2009 at 11:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .