Re: The black art of postgresql.conf tweaking

From: Janning Vygen <vygen(at)gmx(dot)de>
To: pgsql-performance(at)postgresql(dot)org
Cc: Paul Serby <paul(dot)serby(at)clockltd(dot)com>
Subject: Re: The black art of postgresql.conf tweaking
Date: 2004-08-04 13:26:30
Message-ID: 200408041526.30460.vygen@gmx.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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.

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

this keeps your http connection as short as possible, so the apache child is
ready to serve the next client.

Imagine 5 seconds of keepalive 1 second on lingering half-closed tcp
connections and 4 more seconds for transport of uncompressed content.

in this scenario your apache child uses memory an your pooled db connection
for 10 seconds while doing nothing!

in my experience apache in standard configuration can be the main bottleneck.
and teh combination of keepalive off, lingerd and mod_gzip is GREAT and i
didn't found much sites propagating a configuration like this.

kind regards,
janning

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.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Rod Taylor 2004-08-04 13:26:42 Re: Tuning queries on large database
Previous Message Christopher Kings-Lynne 2004-08-04 13:21:51 Re: [PERFORM] Tuning queries on large database