Heikki Linnakangas <hlinnaka@iki.fi> writes:
> On Mon, 29 Aug 2005, 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.
> Would it be a good idea to make them share a single pool? (in 8.2, of
> course).
Possibly, but I'd be worried about increasing contention. Right now
each of those modules has a separate lock and so accesses don't
interfere with each other. With a single pool I think there'd have to
be just one lock. Hard to guess if the effect would be noticeable,
though.
> And how about making the slru page size smaller? clog, subtrans and
> multixact are quite randomly, I think.
No, I disagree. The traffic to all these is concentrated heavily on
active and recent-past transactions. So mostly what you need is the
newest and next-to-newest pages, plus a few free slots for occasional
historical lookups. Making the page size smaller would mean that
we'd more frequently need to traverse the zero-out-a-new-page logic,
which is bad news (particularly for ExtendCLOG, which has to do that
while holding XidGenLock).
The real question in my mind is whether it's worth expending any effort
at all in this area. I think it's inevitable that we'll blow past the
magic 1MB mark in a release or two anyway, and it's certainly already
true that performance is going to suffer terribly if you have to run in
a shared memory segment of that size. So I'm disinclined to put more
than minimal work into supporting such configurations. I think we
should just document 2MB, or even 4MB, as the minimum usable SHMMAX ...
regards, tom lane