On Aug 29, 2005, at 12:41 PM, Tom Lane wrote:
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
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)
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
