Thom Brown wrote: > This database server is currently serving 3 very very busy multi-core web > servers, and we're about to add another 3 to help deal with the load. > > I'm afraid that upgrading is not an option at present because it's in > production. Upgrading within the 8.3 series should involve downtimes measured in seconds - it's just bugfixes so there's no need to dump and restore the database. > I've taken the suggestion of increasing shared buffers and now got > max_connections set to 1500 and shared_buffers set to about a gigabyte. That's a more sensible area for the shared_buffers value, but beware - if you ever have 1500 queries running at once there's a strong possibility that: 1. 1400 of them will take forever 2. You will run out of RAM and the machine will start swapping 3. Possibly leading to out-of-memory problems if you haven't disabled Linux's overcommit option 4. The out-of-memory process killer will start picking things to kill possibly the postmaster - not good. > I actually mentioned pgPool II to my boss earlier, and it's something we > will have to seriously consider, but will have to do some research first. You can do some very clever things with pgpool, but you might find pgbouncer simpler if you just need to spread the load. There's nothing to stop you introducing it step-by-step - the biggest win will be with the shortest queries, so you might be able to isolate part of your application and test it with that. If you've got 8 cores, peak performance will come with max_connections between 8 and 32 I'd guess. -- Richard Huxton Archonet Ltd -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
