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
