Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] default resource limits

From: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
To: <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <peter_e(at)gmx(dot)net>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] default resource limits
Date: 2005-12-25 23:35:45
Message-ID: 2054.24.211.165.134.1135553745.squirrel@www.dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom Lane said:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> Maybe we need to split this into two pieces, given Tom's legitimate
>> concern about semaphore use. How about we increase the allowed range
>> for  shared_buffers and max_fsm_pages, as proposed in my patch, and
>> leave the  max_connections issue on the table? I also wondered if
>> instead of first  setting max_connections and then
>> shared_buffers/max_fsm_pages, we should  try to scale them in synch
>> somehow.
>
> The existing initdb code actually does try to scale them in sync to
> some extent --- take a closer look at the arguments being passed during
> the max-connections test phase. It won't choose a large
> max_connections unless it can simultaneously get 5 times that many
> shared_buffers.

Yes, I know. What I meant was that we could try using one phase
rather than two. But that's only one possible approach.

> I think this probably needs to be more aggressive
> though.  In a
> situation of limited SHMMAX it's probably more important to keep
> shared_buffers as high as we can than to get a high max_connections. We
> could think about increasing the 5x multiplier, adding Min and/or Max
> limits, or some combination.
>

Yes. If we were to base it on the current maxima (1000/100), we could use a
factor of 10, or if on the maxima I am now proposing (4000/250) a factor of
16. Something in that range is about right I suspect.

cheers

andrew




In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2005-12-26 05:09:35
Subject: Re: Fixing row comparison semantics
Previous:From: Qingqing ZhouDate: 2005-12-25 22:04:02
Subject: Re: Incremental Backup Script

pgsql-patches by date

Next:From: Akio IwaasaDate: 2005-12-26 13:34:52
Subject: BUG #2129: dblink problem
Previous:From: Qingqing ZhouDate: 2005-12-25 21:44:41
Subject: Re: Improve XLOG_NO_TRAN related comments

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group