Re: 8.1beta, SunOS and shmget

From: "Thomas F(dot) O'Connell" <tfo(at)sitening(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 8.1beta, SunOS and shmget
Date: 2005-08-30 14:27:51
Message-ID: 4D77A102-E28B-4DDA-B948-6C207AA2FE78@sitening.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Aug 29, 2005, at 12:41 PM, Tom Lane wrote:

> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
>
>> On Mon, Aug 29, 2005 at 11:30:46AM -0400, Tom Lane wrote:
>>
>>> 20 buffers ... ugh. Obviously we are on the hairy edge of no longer
>>> functioning at all in 1MB shared memory. I'm not sure there is a
>>> whole
>>> lot we can do about this, but it's a tad irritating that clog,
>>> subtrans,
>>> and multixact are eating the equivalent of about 16 buffers
>>> (nonconfigurable) while the main buffer pool is so badly starved.
>>>
>
>
>> 8 buffers each, I think, no? That's 32 buffers total.
>>
>
> You're right; I was thinking that NUM_SLRU_BUFFERS was 4, but I see
> it's
> now 8. Did we bump that up on the basis of any solid evidence?
> There's
> 256K of shared memory going into those four dedicated buffer areas,
> which is kind of a lot when you're hoping to fit into 1MB.
>
> I just finished going through the initialization sequence to trace the
> calculation of shared memory size, and what I find in CVS tip is that
> it works out like this:
>
> shared_buffers * 8314
> max_connections * (217.68 * max_locks_per_transaction + 356)
> max_prepared_transactions * (217.68 * max_locks_per_transaction + 576)
> wal_buffers * 8192
> max_fsm_relations * 70
> max_fsm_pages * 6
> plus about 500K fixed space
>
> (These numbers are on a 32-bit machine, some of the multipliers
> would be
> a little higher on 64-bit.)
>
> The formula given in the docs doesn't seem to have been updated
> since 7.2:
> 250 kB + 8.2 kB * shared_buffers + 14.2 kB * max_connections
>
> Most of the bloat since then seems to be accounted for by 2PC and the
> addition of subtrans and multixact buffers.
>
>
>> Maybe we could make them allocate them automatically based on
>> shared_buffers, with a ceiling of 8?
>>
>
> Seems like it'd be reasonable to skinny down the number of dedicated
> buffers when shared_buffers is tiny, but I'm not sure about the
> particular equation to use.
>
> regards, tom lane

Should the new formulation be sent to pgsql-docs? This looks like it
could be worked into a patch pretty easily. Seems like it would make
sense to update the docs for 8.1...

--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC

Strategic Open Source: Open Your i™

http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-469-5150
615-469-5151 (fax)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2005-08-30 14:39:52 Re: Performance gain from reduction of GROUP BY memory
Previous Message Bruce Momjian 2005-08-30 14:23:49 Re: Performance gain from reduction of GROUP BY memory