Re: User concurrency thresholding: where do I look?

Josh Berkus wrote:
> Folks,
>

> 650    105.71    0.02
> 700    106.95    0.02
> 750    107.69    0.02
> 800    106.78    0.02
> 850    108.59    0.02
> 900    106.03    0.02
> 950    106.13    0.02
> 1000    64.58    0.15
> 1050    52.32    0.23
> 1100    49.79    0.25
>
> Tinkering with shared_buffers has had no effect on this threholding (the above
> was with 3gb to 6gb of shared_buffers).   Any ideas on where we should look
> for the source of the bottleneck?

I have seen this as well. I always knocked it up to PG having to
managing so many connections but there are some interesting evidences to
review.

The amount of memory "each" connection takes up. Consider 4-11 meg per
connection depending on various things like number of prepared queries.

Number of CPUs. Obviously 500 connections over 4 CPUS isn't the same as
500 connections over 8 CPUS.

That number of connections generally means a higher velocity, a higher
velocity means more checkpoint segments. Wrong settings with your
checkpoint segments, bgwriter and checkpoint will cause you to start
falling down.

I would also note that our experience is that PG falls down a little
higher, more toward 2500 connections last time I checked, but this was
likely on different hardware.

Joshua D. Drake



--

       === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
              http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/