On Mon, 2 Feb 2004, Kevin Barnard wrote:
> 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.
what do you mean at 2 GB? Is that how much is in kernel cache plus
buffer, plus used, plus etc??? Could you give us the top of top output to
make sure? If most of that is kernel cache, then that's fine. My
experience has been that individual postgresql backends only weigh in at a
mega byte at most, and they share buffer, so 700 connections can be
anywhere from 300meg to 1 gig. the rest would be buffer memory. It's not
a good idea to give up too much to shared buffers, as the database isn't
as good at caching as the kernel.
What do you have in postgresql.conf? sort_mem, shared_buffers, etc???
sort_mem can be a real killer if it lets the processes chew up too much
memory. Once sort_mem gets high enough to make the machine start swapping
it is doing more harm than good being that high, and should usually be
lowered a fair bit.
How many disks in your RAID5? The more the better. Is it hardware with
battery backed cache? If you write much to it it will help to have
battery backed cache on board. If it's a megaraid / LSI board, get the
megaraid2 driver, it's supposedly much faster.
You may find it hard to get postgresql to use any more memory than you
have, as 32 bit apps can only address 2 gigs anyway, but the extra can
certainly be used by the kernel as cache, which will help.
