Alvaro Herrera <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
