On Mon, Jan 11, 2010 at 12:17 PM, Kevin Grittner <
kevin.gritt...@wicourts.gov> wrote:

> Bob Dusek <redu...@gmail.com> wrote:
> > Scott Marlowe <scott.marl...@gmail.com>wrote:
> >> Bob Dusek <redu...@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 via email to