From: david@lang.hm
To: Florian Weimer <fweimer@bfk.de>
Cc: Jeff <threshar@threshar.is-a-geek.com>
Cc: Albe Laurenz <laurenz.albe@wien.gv.at>
Cc: pgsql-performance@postgresql.org
Subject: Re: Performance increase with elevator=deadline
Date: Tue, 15 Apr 2008 12:08:31 -0700 (PDT)
Message-ID: <alpine.DEB.1.10.0804151204120.14908@asgard> (raw)
In-Reply-To: <82od8bi6yv.fsf@mid.bfk.de>
References: <D960CB61B694CF459DCFB4B0128514C201FA62C8@exadv11.host.magwien.gv.at>
<C050E63A-2209-4E89-AA99-6A327CCE7380@torgo.978.org>
<82od8bi6yv.fsf@mid.bfk.de>
On Tue, 15 Apr 2008, Florian Weimer wrote:
> * Jeff:
>
>> 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'll be trying this out on the big array later today. I found it
>> suprising this info wasn't more widespread (the use of CFQ on a good
>> controller).
>
> 3ware might be a bit special because the controller has got very deep
> queues on its own, so many assumptions of the kernel I/O schedulers do
> not seem to apply. Toying with the kernel/controller queue depths
> might help, but I haven't done real benchmarks to see if it's actually
> a difference.
>
> A few days ago, I experienced this: On a machine with a 3ware
> controller, a simple getxattr call on a file in an uncontended
> directory took several minutes because a PostgreSQL dump process was
> running in the background (and some other activity of a legacy
> database which caused frequent fdatasync calls). Clearly, this is
> unacceptable, and I've since switched to the deadline scheduler, too.
> So far, this particular behavior hasn't occurred again.
one other thing to watch out for. up until very recent kernels (2.6.23 or
2.6.24) it was possible for one very busy block device to starve other
block devices. they added isolation of queues for different block devices,
but I've seen reports that the isolation can end up throttling high
performance devices as a result. I haven't had time to really dig into
this, but there are tuning knobs available to adjust the que space
available to different devices and the reports are significantly better
activity on a tuned system.
David Lang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: david@lang.hm, fweimer@bfk.de, threshar@threshar.is-a-geek.com, laurenz.albe@wien.gv.at
Subject: Re: Performance increase with elevator=deadline
In-Reply-To: <alpine.DEB.1.10.0804151204120.14908@asgard>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox