Skip site navigation (1) Skip section navigation (2)

Re: PostgreSQL 8.4 tuning question

From: Devin Ben-Hur <devin(at)ben-hur(dot)net>
To: "Ewan, Michael" <michael(dot)ewan(at)intel(dot)com>
Cc: Portland PostgreSQL <pdxpug(at)postgresql(dot)org>
Subject: Re: PostgreSQL 8.4 tuning question
Date: 2009-07-11 16:20:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pdxpug
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 

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.


In response to

pdxpug by date

Next:From: Webb SpragueDate: 2009-07-15 16:46:01
Subject: Re: July Meeting 7/16/2009 - PostGIS and the Census Data
Previous:From: Josh BerkusDate: 2009-07-10 23:06:46
Subject: Commitfest Code Sprint with PUGs

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group