From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | "Jeff" <threshar(at)torgo(dot)978(dot)org>, "Albe Laurenz *EXTERN*" <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
Cc: | "Grzegorz Jaskiewicz *EXTERN*" <gryzman(at)gmail(dot)com>, "Mark Wong" <markwkm(at)gmail(dot)com>, <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: linux deadline i/o elevator tuning |
Date: | 2009-04-13 15:18:16 |
Message-ID: | 49E31168.EE98.0025.0@wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Jeff <threshar(at)torgo(dot)978(dot)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 not, by itself, conclusive. One of the
nice things about a good scheduler is that it allows multiple writes
to the OS to be combined into a single write to the controller cache.
I think that having a large OS cache and the deadline elevator allowed
us to use what some considered extremely aggressive background writer
settings without *any* discernible increase in OS output to the disk.
The significant measure is throughput from the application point of
view; if you see that drop as cfq causes the disk I/O to drop, *then*
you've proven your point.
Of course, I'm betting that's what you do see....
-Kevin
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2009-04-13 16:44:54 | Re: Postgres 8.x on Windows Server in production |
Previous Message | Jeff | 2009-04-13 14:13:15 | Re: linux deadline i/o elevator tuning |