On Aug 29, 2005, at 12:41 PM, Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.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)