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/


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to