Re: Changing the default configuration

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Changing the default configuration
Date: 2003-02-12 01:23:28
Message-ID: Pine.LNX.4.33.0302111815590.1977-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers pgsql-performance

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?

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Bruno Wolff III 2003-02-12 01:37:48 Re: [HACKERS] Changing the default configuration (was Re:
Previous Message Tatsuo Ishii 2003-02-12 01:10:26 Re: Changing the default configuration

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruno Wolff III 2003-02-12 01:37:48 Re: [HACKERS] Changing the default configuration (was Re:
Previous Message Tatsuo Ishii 2003-02-12 01:10:26 Re: Changing the default configuration

Browse pgsql-performance by date

  From Date Subject
Next Message Bruno Wolff III 2003-02-12 01:37:48 Re: [HACKERS] Changing the default configuration (was Re:
Previous Message Tatsuo Ishii 2003-02-12 01:10:26 Re: Changing the default configuration