At 06:24 PM 1/28/2007, Josh Berkus wrote:
John,

> -work_mem

Depends on the number of concurrent queries you expect to run and what size
sorts you expect them to do.
EXPLAIN ANALYZE is your friend. It will tell you how much data each query is manipulating and therefore how much memory each query will chew.

The next step is to figure out how many of each query will be running concurrently. Summing those will tell you the maximum work_mem each kind of query will be capable of using.

If you have a deep enough understanding of how your pg system is working, then you can set work_mem on a per query basis to get the most efficient use of the RAM in your system.


> -maintenance_work_mem - 50% of the largest table?

Actually, in current code I've found that anything over 256mb doesn't actually
get used.
Is this considered a bug? When will this limit go away? Does work_mem have a similar limit?


> -shared_buffers - max value 50000

Actually, I need to update that. On newer faster multi-core machines you may
want to allocate up to 1GB of shared buffers.

> -effective_cache_size - max 2/3 of available ram, ie 24GB on the
> hardware described above

Yes.
Why? "max of 2/3 of available RAM" sounds a bit hand-wavy. Especially with 32gb, 64GB, and 128GB systems available.

Is there are hidden effective or hard limit  here as well?

For a dedicated pg machine, I'd assume one would want to be very aggressive about configuring the kernel, minimizing superfluous services, and configuring memory use so that absolutely as much as possible is being used by pg and in the most intelligent way given one's specific pg usage scenario.


> -shmmax - how large dare I set this value on dedicated postgres servers?

Set it to 2GB and you'll be covered.
I thought  that on 32b systems the 2GB shmmax limit had been raised to 4GB?
and that there essentially is no limit to shmmax on 64b systems?

What are Oracle and EnterpriseDB recommending for shmmax these days?


My random thoughts,
Ron Peacetree

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to