Re: performance config help

On Mon, Jan 11, 2010 at 12:17 PM, Kevin Grittner <
Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:

> Bob Dusek <redusek(at)gmail(dot)com> wrote:
> > Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>wrote:
> >> Bob Dusek <redusek(at)gmail(dot)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
>