On Thu, 16 Dec 2010, Ski Kacoroski wrote: > Thanks for the info. I wonder if this will make a difference for > machines running on vmware through a vmdk file system? In my email > server case, it was a direct connection to a lun on the SAN.
yes, I would expect that in a virtual machine you are best off with noop as well, the host is going to have it's own scheduler for real disk I/O, and so all that logic is a waste of time for the guest. David Lang > cheers, > > ski > > On 12/16/2010 11:17 AM, Jonathan Nicol wrote: >> Agreed, I've done a fair amount of testing on this and found that NOOP >> always performs better with SANs. I always use it for Amazon EBS >> volumes. On local disks I haven't found much difference between CFQ >> (RedHat default) and Deadline (Ubuntu default), I imagine this depends >> on your workload. Most of my tests have focused on MySQL. >> >> You can add "elevator=noop" to your kernel boot options to make it the >> default. >> >> Jonathan >> >> >> On Dec 16, 2010, at 10:48 AM, 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 >>> >>> -- >>> "When we try to pick out anything by itself, we find it >>> connected to the entire universe" John Muir >>> >>> Chris "Ski" Kacoroski, ckacoro...@nsd.org, 206-501-9803 >>> or ski98033 on most IM services >>> _______________________________________________ >>> 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/ >> >> _______________________________________________ >> 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/ > > _______________________________________________ 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/
