Matthew wrote:
> On Fri, 11 Apr 2008, Jeff wrote:
>> Using 4 of these with a dataset of about 30GB across a few files
>> (Machine has 8GB mem) I went from around 100 io/sec to 330 changing to
>> noop. Quite an improvement. If you have a decent controller CFQ is
>> not what you want. I tried deadline as well and it was a touch
>> slower. The controller is a 3ware 9550sx with 4 disks in a raid10.
>
> I ran Greg's fadvise test program a while back on a 12-disc array. The
> three schedulers (deadline, noop, anticipatory) all performed
> pretty-much the same, with the fourth (cfq, the default) being
> consistently slower.
I use CFQ on some of my servers, despite the fact that it's often slower
in total throughput terms, because it delivers much more predictable I/O
latencies that help prevent light I/O processes being starved by heavy
I/O processes. In particular, an Linux terminal server used at work has
taken a lot of I/O tuning before it delivers even faintly acceptable I/O
latencies under any sort of load.
Bounded I/O latency at the expense of throughput is not what you usually
want on a DB server, where throughput is king, so I'm not at all
surprised that CFQ performs poorly for PostgreSQL. I've done no testing
on that myself, though, because with my DB size and the nature of my
queries most of them are CPU bound anyway.
Speaking of I/O performance with PostgreSQL, has anybody here done any
testing to compare results with LVM to results with the same filesystem
on a conventionally partitioned or raw volume? I'd probably use LVM even
at a performance cost because of its admin benefits, but I'd be curious
if there is any known cost for use with Pg. I've never been able to
measure one with other workloads.
--
Craig Ringer