Re: The black art of postgresql.conf tweaking - Mailing list pgsql-performance

From Thomas Swan
Subject Re: The black art of postgresql.conf tweaking
Date
Msg-id 4110F7E0.4050204@idigx.com
Whole thread Raw
In response to Re: The black art of postgresql.conf tweaking  (Janning Vygen <vygen@gmx.de>)
List pgsql-performance
Janning Vygen wrote:

>Am Mittwoch, 4. August 2004 14:45 schrieb Paul Serby:
>
>
>>Apache on the Web server can take up to 300 connections and PHP is using
>>  pg_pconnect
>>
>>Postgres is set with the following.
>>
>>max_connections = 300
>>shared_buffers = 38400
>>sort_mem = 12000
>>
>>But Apache is still maxing out the non-super user connection limit
>>
The number of connections in apache and in postgresql are the keys.
 From what you've described, apache can have up to 300 child processes.
If this application uses a different identity or db for different
connects then you may have more than one connection open per process
easily exhausting your available connections.   Also,  your application
may open multiple connections to postgresql per process.     See if
setting max_connections in postgres to a larger works, but you may want
to reduce your sort_mem proportionately to keep from overbooking your
system.

>for most websites 300 connections is far too much (imagine even 10 request per
>second for 10 hours a day ends up to 10.8 Mio pages a month)
>
>but anyway: you should first focus on closing your http connection to the user
>as fast as possible. then you dont need so much concurrent connections which
>keep db connections open and uses memory.
>
>I did the following:
>- apache: keepalive off
>- apache patch: lingerd (google for it)
>- apache mod_gzip
>- pg_pconnect
>
>
KeepAlive for 2 or 3 seconds is quite sufficient.  This keeps the
current number of connections down for those browsers that support it,
and keeps the server from leaving too many open.   We found KeepAlive
off caused too many http connections to be opened and closed for our
applications and hardware to keep up.   The benefit is facilitating a
rapid succession of requests: page loads, graphics, embedded objects,
frames, etc.

>p.s: sorry for being slightly off topic and talking about apache but when it
>comes to performance it is always important to look at the complete system.
>
>
Good advice.

pgsql-performance by date:

Previous
From: Valerie Schneider DSI/DEV
Date:
Subject: Re: Tuning queries on large database
Next
From: Michael Adler
Date:
Subject: Re: Performance Bottleneck