On Feb 8, 2010, at 9:49 AM, Josh Berkus wrote: > > Those tests were also done on attached storage. > > So, what this suggests is: > reads: deadline > CFQ > writes: CFQ > deadline > attached storage: deadline > CFQ > >From my experience on reads: Large sequential scans mixed with concurrent random reads behave very differently between the two schedulers. Deadline has _significantly_ higher throughput in this situation, but the random read latency is higher. CFQ will starve the sequential scan in favor of letting each concurrent read get some time. If your app is very latency sensitive on reads, that is good. If you need max throughput, getting the sequential scan out of the way instead of breaking it up into lots of small chunks is critical. I think it is this behavior that causes the delays on writes -- from the scheduler's point of view, a large set of writes is usually somewhat sequential and deadline favors throughput over latency. Generally, my writes are large bulk writes, and I am not very latency sensitive but am very throughput sensitive. So deadline helps a great deal (combined with decently sized readahead). Other use cases will clearly have different preferences. My experience with scheduler performace tuning is on CentOS 5.3 and 5.4. With the changes to much of the I/O layer in the latest kernels, I would not be surprised if things have changed. > Man, we'd need a lot of testing to settle this. I guess that's why > Linux gives us the choice of 4 ... > > --Josh Berkus > > -- > Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
