the other big thing is that the CFQ scheduler is really designed to optimize for single rotational disks.
when you are on a SAN, raid card, SSD or anything that doesn't behave the same way, the optimizations that CFQ does become wasted time and overhead (including introducing delays that have little, if any effect on single disks due to seek times, but are very noticable if you are reading from something that doesn't have seek times). so if you have a sophisticated disk subsystem, you almost always want NOOP David Lang On Thu, 16 Dec 2010, Ski Kacoroski wrote: > Hi, > > We have a communigate pro email server. For some time now we have had > issues where it was limited to about 800 IOPs and we could not figure > out what was going on. Well it fell off the cliff yesterday and we > tried everything. Today on a whim, I changed the I/O scheduler from CFQ > to NOOP and bang, the IOPs jumped to 3500 (maxed out our SAN). The > reason I think it made such a big difference is the communigate uses one > large process with many internal threads instead of several processes. > Anyway, if you are having processes that seem to be I/O bound on linux, > try changing the I/O scheduler as it may help. It is easy to do: > > To see current scheduler > cat /sys/block/<device>/queue/scheduler > noop anticipatory deadline [cfq] > > To change it: > echo 'NOOP' /sys/block/<device>/queue/scheduler > cat /sys/block/<device>/queue/scheduler > [noop] anticipatory deadline cfq > > cheers, > > ski > > _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
