From: Bob Dusek <redusek@gmail.com>
To: pgsql-performance@postgresql.org
Subject: Re: performance config help
Date: Mon, 11 Jan 2010 12:54:48 -0500
Message-ID: <61039b861001110954j67bd0efex500a91e7c2b0fd74@mail.gmail.com> (raw)
In-Reply-To: <4B4B08E1020000250002E185@gw.wicourts.gov>
References: <61039b861001110544o2c352763q13dcf9d78a156714@mail.gmail.com>
<dcc563d11001110550s2af6d559l5db495d5e0fc6a57@mail.gmail.com>
<61039b861001110842g15bb1f26jc50b6e6762e01427@mail.gmail.com>
<4B4B08E1020000250002E185@gw.wicourts.gov>
On Mon, Jan 11, 2010 at 12:17 PM, Kevin Grittner <
Kevin.Grittner@wicourts.gov> wrote:
> Bob Dusek <redusek@gmail.com> wrote:
> > Scott Marlowe <scott.marlowe@gmail.com>wrote:
> >> Bob Dusek <redusek@gmail.com> wrote:
>
> >>> 4X E7420 Xeon, Four cores (for a total of 16 cores)
>
> >> What method of striped RAID?
> >
> > RAID-0
>
> I hope you have a plan for what to do when any one drive in this
> array fails, and the entire array is unusable.
>
Point noted.
> Anyway, my benchmarks tend to show that best throughput occurs at
> about (CPU_count * 2) plus effective_spindle_count. Since you seem
> to be fully cached, effective_spindle_count would be zero, so I
> would expect performance to start to degrade when you have more than
> about 32 sessions active.
>
That's a little disheartening for a single or dual CPU system.
> > We actually see degredation when we get more than 40 concurrent
> > requests.
>
> Close enough.
>
> > when we run 200+ requests, we see multi-second queries.
>
> No surprise there. Your vmstat output suggests that context
> switches are becoming a problem, and I wouldn't be surprised if I
> heard that the network is an issue. You might want to have someone
> take a look at the network side to check.
>
This is all happening on a LAN, and network throughput doesn't seem to be an
issue. It may be a busy network, but I'm not sure about a problem. Can you
elaborate on your suspicion, based on the vmstat? I haven't used vmstat
much.
>
> You want to use some connection pooling which queues requests when
> more than some configurable number of connections is already active
> with a request. You probably want to run that on the server side.
> As for the postgresql.conf, could you show what you have right now,
> excluding all comments?
>
The problem with connection pooling is that we actually have to achieve more
than 40 per second, which happens to be the sweet spot with our current
config.
I posted our changes from the default in a reply to another message. I
don't want to duplicate. Can you check those out?
>
> -Kevin
>
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: redusek@gmail.com
Subject: Re: performance config help
In-Reply-To: <61039b861001110954j67bd0efex500a91e7c2b0fd74@mail.gmail.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