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

Re: shared_buffer value

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Anjan Dave <adave(at)vantage(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: shared_buffer value
Date: 2004-01-16 17:20:24
Message-ID: Pine.LNX.4.33.0401161012170.27657-100000@css120.ihs.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Fri, 16 Jan 2004, Anjan Dave wrote:

> 68 processes: 67 sleeping, 1 running, 0 zombie, 0 stopped
> CPU0 states:   3.1% user   4.4% system    0.0% nice   0.0% iowait  92.0%
> idle
> CPU1 states:   0.0% user   3.2% system    0.0% nice   0.0% iowait  96.3%
> idle
> CPU2 states:   0.4% user   0.3% system    0.0% nice   0.0% iowait  98.3%
> idle
> CPU3 states:   0.3% user   1.0% system    0.0% nice   0.0% iowait  98.2%
> idle
> Mem:  3874188k av, 3622296k used,  251892k free,       0k shrd,  322372k
> buff
>                    2369836k actv,  454984k in_d,   44568k in_c
> Swap: 4096532k av,   24552k used, 4071980k free                 2993384k
> cached

Note that that machine has 2993384k of kernel cache.  This means that 
after all that it's doing, there's about 3 gigs of free memory, and the 
kernel is just using it to cache files.  Should a process need that 
memory, the kernel would free it right up.

So, you don't have to worry about setting the buffers too high in 
postgresql and running out of memory, you're not even close.

I'd crank up sort mem to 4 or 8 meg or so, and the shared buffers to 
something a little higher, say 5000 to 10000 or so.  Note that there is a 
point of diminishing returns in postgresql where if you allocate too much 
buffer memory, it gets slower than just letting the kernel do it.

>   PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU
> COMMAND
>  4258 postgres  16   0 88180  86M 85796 S     2.1  2.2  14:55   0

this says that this process is using 88 meg or so of ram, and of that 88 
mef or so, 84 meg is shared between it and the other postgres processes.

>  5260 postgres  15   0 85844  83M 84704 S     0.0  2.2   2:51   1

Same here.  That means that this single process represents a delta of 1 
meg or so.

>  3157 postgres  15   0 50364  49M 48484 S     0.0  1.2   0:02   3

Delta is about 2 meg.
and so forth.  I.e. you're not using 50 to 80 megs per process, only 2 
megs or so, plus the 80 meg of shared memory.

> I am not sure how do I calculate whether 80MB shared_buffer (in
> postgresql.conf)should be increased or decreased from the above values,
> because during higher loads, the number of postmaster instances go up to
> 100 (limited by max connections), each at an RSS of about 87MB...

Generally, increase it until it doesn't make things go faster any more.  
80 meg is pretty small, especially for a machine with 4 gigs of ram.  The 
upper limit is generally found to be around 256 Meg or so, and that's what 
we use on our machine at work.  Note this may make smaller queries slower, 
since the overhead of maintaining a large buffer costs a bit, but it makes 
larger queries faster, so it's a trade off.


In response to

pgsql-performance by date

Next:From: Stephan SzaboDate: 2004-01-16 17:48:18
Subject: Re: subquery and table join, index not use for table
Previous:From: Rod TaylorDate: 2004-01-16 17:01:39
Subject: Re: [PERFORM] Postgres on Netapp

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