Peter Eisentraut <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq