From: Shaun Thomas <sthomas@peak6.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: pgsql-performance@postgresql.org
Cc: Claire Chang <yenhsiac@yahoo.com>
Subject: Re: Postgres 8.4 memory related parameters
Date: Fri, 5 Aug 2011 12:09:57 -0500
Message-ID: <4E3C23E5.1010409@peak6.com> (raw)
In-Reply-To: <4E3BBED6020000250003FB6D@gw.wicourts.gov>
References: <1312489633.71838.YahooMailClassic@web31912.mail.mud.yahoo.com>
<4E3ABCFB020000250003FAF4@gw.wicourts.gov>
<4E3B08D3.606@peak6.com>
<4E3ACA8C020000250003FB05@gw.wicourts.gov>
<4E3B13E8.7050002@peak6.com>
<4E3ACEB4020000250003FB10@gw.wicourts.gov>
<4E3B15EB.1020603@peak6.com>
<4E3BB14A020000250003FB41@gw.wicourts.gov>
<4E3BFC66.4040501@peak6.com>
<4E3BBED6020000250003FB6D@gw.wicourts.gov>
On 08/05/2011 09:58 AM, Kevin Grittner wrote:
> What I'm saying is that if processes are blocked waiting for disk
> they are not going to be using CPU, and there is room for that many
> additional processes to be useful, as the CPUs and other drives
> would otherwise be sitting idle.
Haha. The way you say that made me think back on the scenario with 4
cpus and 1 disk. Naturally that kind of system is IO starved, and will
probably sit at IO-wait at 10% or more on any kind of notable activity
level. I was like... "Well, so long as everything is waiting anyway, why
not just increase it to 100?"
Now, typically you want to avoid context switching. Certain caveats need
to be made for anything with less than two, or even four cpus because of
various system and Postgres monitoring/maintenance threads. My own
benchmarks illustrate (to me, anyway) that generally, performance peaks
when PG threads equal CPU threads *however they're supplied*.
Never minding fudge factor for idling connections waiting on IO, which
you said yourself can be problematic the more of them there are. :)
I'd say just put it at 2x, maybe 3x, and call it good. Realistically you
won't really notice further tweaking, and a really active system would
converge to cpu count through a pooler and be cached to the gills anyway.
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
312-676-8870
sthomas@peak6.com
______________________________________________
See http://www.peak6.com/email_disclaimer.php
for terms and conditions related to this email
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: sthomas@peak6.com, Kevin.Grittner@wicourts.gov, yenhsiac@yahoo.com
Subject: Re: Postgres 8.4 memory related parameters
In-Reply-To: <4E3C23E5.1010409@peak6.com>
* 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