Re: User concurrency thresholding: where do I look?

["Joshua D. Drake" <jd(at)commandprompt(dot)com>]

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/