Increasing number of PG connections. - Mailing list pgsql-performance

From Kevin Barnard
Subject Increasing number of PG connections.
Date
Msg-id 401E4D27.26927.3254D8C1@localhost
Whole thread Raw
Responses Re: Increasing number of PG connections.  (Qing Zhao <qzhao@quotefx.net>)
Re: Increasing number of PG connections.  ("scott.marlowe" <scott.marlowe@ihs.com>)
List pgsql-performance
I am running a Dual Xeon hyperthreaded server with 4GB RAM RAID-5.  The only
thing running on the server is Postgres running under Fedora.  I have a 700
connection limit.

The DB is setup as a backend for a very high volume website.  Most of the queries
are simple, such as logging accesses, user login verification etc.  There are a few
bigger things suchas reporting etc but for the most part each transaction lasts less
then a second.  The connections are not persistant (I'm using pg_connect in PHP)

The system was at 2 GB with a 400 connection limit.  We ran into problems because
we hit the limit of connections during high volume.

1.  Does 400 connections sound consistant with the 2GB of RAM?  Does 700 sound
good with 4 GB.  I've read a little on optimizing postgres.  Is there anything else I can
do maybe OS wise to increase how many connections I get before I start swapping?

2.  Are there any clustering technologies that will work with postgres?  Specifically I'm
looking at increasing the number of connections.

The bottom line is since the website launched (middle of January) we have increased
the number of http connections, and increased bandwidth allowances by over 10
times.  The site continues to grow and we are looking at our options.  Some of the
ideas have been possible DB replication.   Write to master and read from multiple
slaves.  Other ideas including increasing hardware.

This is the biggest site I have ever worked with.  Almost everything else fits in a T1
with a single DB server handling multiple sites.  Does anybody with experence in this
realm have any suggestions?

Thank you in advance for whatever help you can provide.
--
Kevin Barnard



pgsql-performance by date:

Previous
From: Rod Taylor
Date:
Subject: Re: "Overlaping" indexes
Next
From: Orion Henry
Date:
Subject: pg_stat_activity