Re: Changing the default configuration - Mailing list pgsql-hackers

From scott.marlowe
Subject Re: Changing the default configuration
Date
Msg-id Pine.LNX.4.33.0302111815590.1977-100000@css120.ihs.com
Whole thread Raw
In response to Re: Changing the default configuration  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Responses Re: Changing the default configuration  (Tatsuo Ishii <t-ishii@sra.co.jp>)
List pgsql-hackers
On Wed, 12 Feb 2003, Tatsuo Ishii wrote:

> > My other pet peeve is the default max connections setting.  This should be 
> > higher if possible, but of course, there's always the possibility of 
> > running out of file descriptors.
> > 
> > Apache has a default max children of 150, and if using PHP or another 
> > language that runs as an apache module, it is quite possible to use up all 
> > the pgsql backend slots before using up all the apache child slots.
> > 
> > Is setting the max connections to something like 200 reasonable, or likely 
> > to cause too many problems?
> 
> It likely. First you will ran out kernel file descriptors. This could
> be solved by increasing the kernel table or lowering
> max_files_per_process, though. Second the total throughput will
> rapidly descrease if you don't have enough RAM and many
> CPUs. PostgreSQL can not handle many concurrent
> connections/transactions effectively. I recommend to employ some kind
> of connection pooling software and lower the max connections.

Don't know if you saw my other message, but increasing max connects to 200 
used about 10% of all my semaphores and about 10% of my file handles.  
That was while running pgbench to create 200 simo sessions.

Keep in mind, on my fairly small intranet database server, I routinely 
have >32 connections, most coming from outside my webserver.  Probably no 
more than 4 or 5 connects at a time come from there.  These are all things 
like Windows boxes with ODBC running access or something similar.  Many of 
the connections are idle 98% of the time, and use little or no real 
resources, even getting swapped out should the server need the spare 
memory (it doesn't :-)  that machine is set to 120 max simos if I remember 
correctly.

while 200 may seem high, 32 definitely seems low.  So, what IS a good 
compromise?  for this and ALL the other settings that should probably be a 
bit higher.  I'm guessing sort_mem or 4 or 8 meg hits the knee for most 
folks, and the max fsm settings tom has suggested make sense.

What wal_sync method should we make default?  Or should we pick one based 
on the OS the user is running?




pgsql-hackers by date:

Previous
From: Bruno Wolff III
Date:
Subject: Re: Changing the default configuration (was Re: [pgsql-advocacy]
Next
From: Lamar Owen
Date:
Subject: Contract Programmer Advice.