On Thu, 9 Apr 2009, Grzegorz Jaśkiewicz wrote:
(btw, CFQ is the anticipatory scheduler).
No, CFQ and anticipatory are two completely different schedulers. You can
choose between them.
But the anticipatory scheduler basically makes the huge assumption that you
have one single disc in the system that takes a long time to seek from one
place to another. This assumption fails on both RAID arrays and SSDs, so I'd
be interested to see some numbers to back that one up.
So to avoid possible starvation problem, it will wait for short amount
of time - in hope that app will want to read possibly next block on
disc, and putting that request at the end of queue could potentially
starve it. (that reason alone is why 2.6 linux feels so much more
responsive).
This only actually helps if the assumptions I stated above are true.
Anticipatory is an opportunistic scheduler - it actually witholds requests
from the disc as you describe, in the hope that a block will be fetched
soon right next to the last one. However, if you have more than one disc,
then witholding requests means that you lose the ability to perform more
than one request at once. Also, it assumes that it will take longer to
seek to the next real request that it will for the program to issue its
next request, which is broken on SSDs. Anticipatory attempts to increase
performance by being unfair - it is essentially the opposite of CFQ.
Matthew
--
Now you see why I said that the first seven minutes of this section will have
you looking for the nearest brick wall to beat your head against. This is
why I do it at the end of the lecture - so I can run.
-- Computer Science lecturer
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
