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

Re: confused of buffers and memory settings

From: Michael Monnerie <michael(dot)monnerie(at)it-management(dot)at>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: confused of buffers and memory settings
Date: 2008-04-23 11:19:23
Message-ID: 200804231319.24090@zmi.at (view raw or flat)
Thread:
Lists: pgsql-admin
On Mittwoch, 23. April 2008 Gerd König wrote:
> The db will be accessed heavily (~20 requests/sec.) 
> with a read/write ration of 50:50, yes, a lot of write activity.

Not really heavy, I would say, but maybe your transactions are very big 
and produce a lot of I/O.

> I thought of setting "shared_buffers" to 750000 (~6GB) but how
> depends this on the kernel buffer setting in /etc/sysctl.conf (what
> is the interaction between these two settings?).
> I know the variable "shmmax" can be defined, but currently there's no
> such entry.

# Shared Mem Maximum example:
kernel.shmmax = 950123456
# do not allow memory overcommit to prevent database crashes
vm.overcommit_memory=2

> The meaning of "work_mem" / "maintenance_work_mem" and "wal_buffers"
> is also not clear. The maintenance_work_mem influences the size of
> the WAL logs..?!?
> What else are "top performance related" options for the usage
> scenario I described earlier ?

http://www.postgresql.org/docs/8.3/interactive/runtime-config-resource.html

mfg zmi
-- 
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0676/846 914 666                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: www.keyserver.net                   Key-ID: 1C1209B4

In response to

pgsql-admin by date

Next:From: Dimitri FontaineDate: 2008-04-23 12:24:43
Subject: Re: confused of buffers and memory settings
Previous:From: Guillaume LelargeDate: 2008-04-23 11:11:17
Subject: Re: confused of buffers and memory settings

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