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

Re: [PATCHES] default resource limits

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] default resource limits
Date: 2006-01-01 00:04:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> In experimenting I needed to set this at 20 for it to bite much. If we 
> wanted to fine tune it I'd be inclined to say that we wanted 
> 20*connections buffers for the first, say, 50  or 100 connections and 10 
> or 16 times for each connection over that. But that might be getting a 
> little too clever - something we should leave to a specialised tuning 
> tool. After all, we try these in fairly discrete jumps anyway. Maybe a 
> simple factor around 20 would be sufficient.

I think 10 is probably a good compromise value.  If we set it to 20
we'll find "make check" failing on Darwin because Apple's standard
SHMMAX value doesn't allow more than about 300 buffers ... and the
regression tests want max_connections to be at least 20.

I noticed while fooling with this on my laptop that initdb was selecting
a shared_buffers value less than the value it had just proved would work
:-(.  This is because the list of shared_buffers values it was probing
did not include all the values corresponding to values tried during the
max_connections scan.  I've added documentation about that gotcha.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Doug RoyerDate: 2006-01-01 00:31:54
Subject: Re: EINTR error in SunOS
Previous:From: Greg StarkDate: 2006-01-01 00:03:22
Subject: Re: EINTR error in SunOS

pgsql-patches by date

Next:From: Bruce MomjianDate: 2006-01-01 04:18:48
Subject: Checks for command string
Previous:From: Tom LaneDate: 2005-12-31 19:43:26
Subject: Re: TODO item: list prepared queries

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