Jeff wrote:
> If you have a halfway OK raid controller, CFQ is useless. You can
fire
> up something such as pgbench or pgiosim, fire up an iostat and then
> watch your iops jump high when you flip to noop or deadline and
> plummet on cfq.
An interesting data point, but not, by itself, co
On Apr 10, 2009, at 2:47 AM, Albe Laurenz *EXTERN* wrote:
Grzegorz Jaskiewicz wrote:
acording to kernel folks, anticipatory scheduler is even better for
dbs.
Oh well, it probably means everyone has to test it on their own at
the
end of day.
In my test case, noop and deadline performed we
Grzegorz Jaskiewicz wrote:
> acording to kernel folks, anticipatory scheduler is even better for dbs.
> Oh well, it probably means everyone has to test it on their own at the
> end of day.
In my test case, noop and deadline performed well, deadline being a little
better than noop.
Both anticipato
The anticipatory scheduler gets absolutely atrocious performance for server
workloads on even moderate server hardware. It is applicable only to single
spindle setups on desktop-like worlkoads.
Seriously, never use this for a database. It _literally_ will limit you to
100 iops maximum random acc
On Thu, Apr 9, 2009 at 7:53 AM, Mark Wong wrote:
> On Thu, Apr 9, 2009 at 7:00 AM, Mark Wong wrote:
>> Hi all,
>>
>> Has anyone experimented with the Linux deadline parameters and have some
>> experiences to share?
>
> Hi all,
>
> Thanks for all the responses, but I didn't mean selecting deadline
Arjen van der Meijden wrote:
> On 9-4-2009 16:09 Kevin Grittner wrote:
>> I haven't benchmarked it, but when one of our new machines seemed a
>> little sluggish, I found this hadn't been set. Setting this and
>> rebooting Linux got us back to our normal level of performance.
>
> Why would you r
On Thu, Apr 9, 2009 at 7:00 AM, Mark Wong wrote:
> Hi all,
>
> Has anyone experimented with the Linux deadline parameters and have some
> experiences to share?
Hi all,
Thanks for all the responses, but I didn't mean selecting deadline as
much as its parameters such as:
antic_expire
read_batch_e
On 9-4-2009 16:09 Kevin Grittner wrote:
I haven't benchmarked it, but when one of our new machines seemed a
little sluggish, I found this hadn't been set. Setting this and
rebooting Linux got us back to our normal level of performance.
Why would you reboot after changing the elevator? For 2.6-
On Thu, Apr 9, 2009 at 3:42 PM, Kevin Grittner
wrote:
> Grzegorz Jaœkiewicz wrote:
>> (btw, CFQ is the anticipatory scheduler).
>
> These guys have it wrong?:
>
> http://www.wlug.org.nz/LinuxIoScheduler
sorry, I meant it replaced it :) (is default now).
--
GJ
--
Sent via pgsql-performance
On Thu, 9 Apr 2009, Grzegorz Jaśkiewicz wrote:
(btw, CFQ is the anticipatory scheduler).
No, CFQ and anticipatory are two completely different schedulers. You can
choose between them.
But the anticipatory scheduler basically makes the huge assumption that you
have one single disc in the sys
Grzegorz Jaœkiewicz wrote:
> (btw, CFQ is the anticipatory scheduler).
These guys have it wrong?:
http://www.wlug.org.nz/LinuxIoScheduler
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/ma
Matthew Wakeling wrote:
> On Thu, 9 Apr 2009, Grzegorz Jaœkiewicz wrote:
>> acording to kernel folks, anticipatory scheduler is even better for
>> dbs. Oh well, it probably means everyone has to test it on their
>> own at the end of day.
>
> But the anticipatory scheduler basically makes the hu
On Thu, Apr 9, 2009 at 3:32 PM, Matthew Wakeling wrote:
> On Thu, 9 Apr 2009, Grzegorz Jaśkiewicz wrote:
>>
>> acording to kernel folks, anticipatory scheduler is even better for dbs.
>> Oh well, it probably means everyone has to test it on their own at the
>> end of day.
>
> But the anticipatory
On Thu, 9 Apr 2009, Grzegorz Jaśkiewicz wrote:
acording to kernel folks, anticipatory scheduler is even better for dbs.
Oh well, it probably means everyone has to test it on their own at the
end of day.
But the anticipatory scheduler basically makes the huge assumption that
you have one single
acording to kernel folks, anticipatory scheduler is even better for dbs.
Oh well, it probably means everyone has to test it on their own at the
end of day.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Mark Wong wrote:
> Has anyone experimented with the Linux deadline parameters and
> have some experiences to share?
We've always used elevator=deadline because of posts like this:
http://archives.postgresql.org/pgsql-performance/2008-04/msg00148.php
I haven't benchmarked it, but when one of
Hi all,
Has anyone experimented with the Linux deadline parameters and have
some experiences to share?
Regards,
Mark
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
17 matches
Mail list logo
