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
Jeff thres...@torgo.978.org 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
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 anticipatory
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
Mark Wong mark...@gmail.com 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,
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:
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
On Thu, Apr 9, 2009 at 3:32 PM, Matthew Wakeling matt...@flymine.org 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
Matthew Wakeling matt...@flymine.org 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
Grzegorz Jaœkiewicz gryz...@gmail.com 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:
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
On Thu, Apr 9, 2009 at 3:42 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Grzegorz Jaœkiewicz gryz...@gmail.com 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).
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
On Thu, Apr 9, 2009 at 7:00 AM, Mark Wong mark...@gmail.com 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:
Arjen van der Meijden acmmail...@tweakers.net 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.
On Thu, Apr 9, 2009 at 7:53 AM, Mark Wong mark...@gmail.com wrote:
On Thu, Apr 9, 2009 at 7:00 AM, Mark Wong mark...@gmail.com 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
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
17 matches
Mail list logo
