Craig James wrote:
> This data is good enough for what I'm doing. There were
> reports from non-RAID users that the I/O scheduling could
> make as much as a 4x difference in performance (which makes
> sense for non-RAID), but these tests show me that three of
> the four I/O schedulers are within 10% of each other. Since
> this matches my intuition of how battery-backed RAID will
> work, I'm satisfied. If our servers get overloaded to the
> point where 10% matters, then I need a much more dramatic
> solution, like faster machines or more machines.
I should comment on this as I am the one who reported the
big performance increase with the deadline scheduler.
I was very surprised at this increase myself as I had not seen
any similar reports, so I thought I should share it for whatever
it is worth.
Our SAN *is* a RAID-5 with lots of cache, so there must be a flaw
in your intuition.
Performance measures depend a lot on your hardware and
software setup (e.g. kernel version in this case) and on the
specific load. The load we used was a real life load, collected
over seveal hours and extracted from the log files.
My opinion is that performance observations can rarely be
generalized - I am not surprised that with a different system
and a different load you observe hardly any difference between
"cfq" and "deadline".
For the record, in our test case "noop" performed practically
as good as "deadline", while the other two did way worse.
Like yourself, I have wondered why different I/O scheduling
algorithms should make so much difference.
Here is my home-spun theory of what may happen; tear it apart
and replace it with a better one at your convenience:
Our SAN probably (we're investigating) has its own brains to
optimize I/O, and I guess that any optimization that the kernel
does can only deteriorate performance because the two algorithms
might "step on each other's toes". This is backed by "noop"
performing well.
I believe that caching will not make much difference, because the
cache is way smaller than the database, and whatever is neither in
the shared buffer nor in the kernel filesystem cache is also not
likely to be in the storage system's cache. Remember that our load
was read-only.
Yours,
Laurenz Albe