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/
