I can only share with you what i know, but from my experience, the "generic" answer is that one should tune with benchmarks to their specific configuration and workload/access patterns. From all the I/O tuning work I've done, the one thing I've learned is that every situation is different, and although I have a few "rules of thumb" that I've derived from past experience, they only serve as guidelines.
That said, from what I've seen, the default (in RHEL) read ahead cache setting in Linux is way too small for every tuning project I've worked on where RAID-5/6/10 was involved and for any of access patterns/workloads I've had to tune for. So, generally speaking, I always expect that I'll be increasing this parameter, even for random I/O situations. Just to pull some numbers I happen to have handy on this computer, below are some of the benchmark results I got where we also looked at random I/O. This particular server was an HP server using an older smart array RAID controller. We were using RAID-10. In this particular case, we found that the 'deadline' scheduler worked best, and we were testing (using IOzone) the effects of read ahead cache tuning: with Deadline + 4M read ahead " Initial write " 149996.51 " Rewrite " 94494.06 " Read " 231819.48 " Re-read " 230964.92 " Random read " 202522.65 " Random write " 102325.98 with deadline + 8M read ahead " Initial write " 149163.65 " Rewrite " 99006.81 " Read " 237305.72 " Re-read " 236885.96 " Random read " 259195.10 " Random write " 133553.85 with deadline + 16M read ahead " Initial write " 144160.41 " Rewrite " 136824.62 " Read " 240274.27 " Re-read " 239173.90 " Random read " 242373.06 " Random write " 88325.02 You'll notice that I didn't even test the default 256k, but that's because I already know having such a small read ahead resulted in very slow I/O. You'll see that from 4M to 8M read ahead, there is a significant improvement (at least for this benchmark) in both random read and writes, while the sequential I/O tests had no significant change. Going to 16M actually sees a decrease in random writes, so there is a point where "more is less". Now, I'm no guru, and I can't tell you exactly "why" the benchmark results exhibit this behavior. All I know is that this is one of the parameters I tune that can change the results of the benchmarks I use, in the above case, it was IOzone. The two things I do know are: 1. when working on RAID-5/6/10, I've found that the default read-ahead cache in RHEL is insufficient for every tuning profile i've worked on. I almost always start at 4M and move up from there, sometimes seeing benefits even up to 32MB. But "more isn't always better" in some cases, which seems to have correlation with RAID level and controller type. 2. i've done my share of "theorizing" what type of I/O behavior to expect for any given configuration. more often that I'd like to admit, the benchmark results end up being contrary to my "theories". so, when I'm tuning for a customer, I focus on the numbers first and worry about trying to find the correct theory that explains the results later. I'm not always happy that I can't exactly explain the results, but at least the results have made the people i've worked for happy. -Bond -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of L A Walsh Sent: Friday, December 04, 2009 2:38 AM To: [email protected] Subject: read-ahead side effects? (was Re: R900 internal disks I/O slow!!!!) While that read-ahead value will help a linear read bench mark, what does it do for random-access? If you have a few milliseconds delay between each seek you might end up reading lots of extra sectors into the disk cache, invalidating other data that might actually be accessed again. Theoretically, that is... Dunno about actual practice, as I suppose it would depend on workload... If I'm writing to a blockdev (like copying files to a file system), it has to do some reads to pull in the directories -- will having it set to read another full 8MB after each dir read affect write performance? I don't know, but seems like it 'could'... ?? -l _______________________________________________ Linux-PowerEdge mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/linux-poweredge Please read the FAQ at http://lists.us.dell.com/faq _______________________________________________ Linux-PowerEdge mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/linux-poweredge Please read the FAQ at http://lists.us.dell.com/faq
