Re: PostgreSQL 8.4 tuning question

Ewan, Michael wrote:
> kernel.shmmax = 18446744073709551615
> kernel.shmall = 1152921504606846720
>
> I'm assuming I should just shake my head, walk away, and not try to
> figure out what Novell is doing here.

No real advice about tuning beyond what you've already read, but wanted
to point out that those two enormous numbers are 2^64-1 and 2^60-1
respectively.

So, Novell's SHMMAX is specifying the largest allowed shared memory
segment as the largest range of a 64bit address. This probably has
little overhead, but should more reasonably be set to a number less than
your real physical memory.

Their SHMALL seems silly. SHMALL is the total shared memory available
and is measured in pages under Linux. The standard page size is 4K ( $
getconf PAGE_SIZE ), so, if Novel was following their 64bit maxuint
pattern, I would have expected their shmall to be 2^52.

On a system with one principle shared memory consumer (eg a db server),
just pick your shmmax as the largest amount of your real memory you want
any software to use, set shmall to shmax/PAGE_SIZE, and configure your
db to use less shared memory than shmmax.

You'll probably find pg shared buffers somewhere between 4G and 10G of
your 32G total will be effective, but it depends a lot on the specifics
of your usage.

--
-Devin