On Feb 9, 2010, at 10:37 PM, Greg Smith wrote:
> Jeff wrote:
>> I'd done some testing a while ago on the schedulers and at the time
>> deadline or noop smashed cfq. Now, it is 100% possible since then
>> that they've made vast improvements to cfq and or the VM to get better
>> or similar performance. I recall a vintage of 2.6 where they severely
>> messed up the VM. Glad I didn't upgrade to that one :)
>>
>> Here's the old post:
>> http://archives.postgresql.org/pgsql-performance/2008-04/msg00155.php
>
> pgiosim doesn't really mix writes into there though, does it? The mixed
> read/write situations are the ones where the scheduler stuff gets messy.
>
Also, read/write mix performance depend on the file system not just the scheduler.
The block device readahead parameter can have a big impact too.
If you test xfs, make sure you configure the 'allocsize' mount parameter properly as well. If there are any sequential
readsor writes in there mixed with other reads/writes, that can have a big impact on how fragmented the filesystem
gets.
Ext3 has several characteristics for writes that might favor cfq that other file systems do not. Features like delayed
allocation,extents, and write barriers significantly change the pattern of writes seen by the I/O scheduler.
In short, one scheduler may be best for one filesystem, but not a good idea for others.
And then on top of that, it all depends on what type of DB you're running. Lots of small fast mostly read queries?
Largenumber of small writes? Large bulk writes? Large reporting queries? Different configurations and tuning is
requiredto maximize performance on each.
There is no single rule for Postgres on Linux that I can think of other than "never have ext3 in 'ordered' or 'journal'
modefor your WAL on the same filesystem as your data".
> --
> Greg Smith 2ndQuadrant Baltimore, MD
> PostgreSQL Training, Services and Support
> greg@2ndQuadrant.com www.2ndQuadrant.com
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
