Re: [PATCH] Don't bail with legitimate -N/-B options

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane wrote:
>> I think at the time we set the current minimum -B we were still
>> intending that you could run in a half meg or so SHMMAX allocation.
>> That's certainly history. Maybe we should target 2 meg as the rock
>> bottom minimum?

> That makes sense to me. It corresponds to 128 connections under the old
> arithmetic, which seems reasonable all around.

I did a bit of experimentation on a 64-bit machine (which is probably a
bit hungrier than a 32-bit machine for shared memory, but not enormously
so). With SHMMAX set to exactly 2MB, the smallest configuration that
initdb tries,

--max_connections=10 --shared_buffers=50 --max_fsm_pages=20000

fits with about 100K to spare. You can get to 100 buffers if you back
off the other two parameters even more, but there's no hope at all of
getting to 200.

At SHMMAX = 4MB you can get up to combinations like this

--max_connections=20 --shared_buffers=285 --max_fsm_pages=20000
--max_connections=10 --shared_buffers=314 --max_fsm_pages=20000

which still look pretty tiny.

There are a couple of things we could hope to do to make this a bit more
tolerable. One is to get rid of FSM in its current form, which was
already on my hit list for 8.4. That would buy about 180K to put back
into the buffer arena, given the FSM parameters used here. Another idea
that's been kicked around is merging the dedicated SLRU buffers into the
common buffer pool. Those are currently hardwired to 64 buffers, which
looks like a lot in this context. I'm still not sure about the
potential concurrency costs (or benefits?) of eliminating SLRU, but it
seems worth looking at, particularly seeing that the fixed allocation is
bad at the high end as well as the low end. Or we could keep the SLRU
areas separate but make their buffer counts tunable instead of fixed.

Anyway, it seems that we cannot raise the minimum value of
shared_buffers to 200, or even 100, unless we are prepared to blow off
SHMMAX = 2MB or do something about the fixed SLRU allocation. I'm
not sure whether 2MB is still an interesting number; is anyone aware
of systems that have that as the default SHMMAX? It seems possible
that targeting 4MB instead of 2MB as the minimum might not change
matters for anyone, in terms of whether they have to reconfigure their
kernel or not.

regards, tom lane