To: tgl@sss.pgh.pa.us
Cc: christian.bucanac@mindark.com, pgsql-general@postgresql.org
Subject: Re: Performance tuning for linux, 1GB RAM, dual CPU? 
In-Reply-To: <23761.994870319@sss.pgh.pa.us>
References: <5146853DD571D411AC54000102070D611C7F10@MINGBGNTS02>
	<23761.994870319@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20010712134958W.t-ishii@sra.co.jp>
Date: Thu, 12 Jul 2001 13:49:58 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Lines: 27

> Christian Bucanac <christian.bucanac@mindark.com> writes:
> >> I am going to try 768M (98304) for buffers and 6144 (6144 * 32 = 192M)
> >> for sort mem. This way with the DB server serving a max of 32 application
> >> servers the kernel and other processes should still have the last 64Mb RAM.
> 
> This is almost certainly a lousy idea.  You do *not* want to chew up all
> available memory for PG shared buffers; you should leave a good deal of
> space for kernel-level disk buffers.
> 
> Other fallacies in the above: (1) you're assuming the SortMem parameter
> applies once per backend, which is not the case (it's once per sort or
> hash step in a query, which could be many times per backend); (2) you're
> not allowing *anything* for any space usage other than shared disk
> buffers and sort memory.
> 
> The rule of thumb I recommend is to use (at most) a quarter of real RAM
> for shared disk buffers.  I don't have hard measurements to back that
> up, but I think it's a lot more reasonable as a starting point than
> three-quarters of RAM.

In my testing with *particluar* environment (Linux kernel 2.2.x,
pgbench), it was indicated that too many shared buffers reduced the
performance even though there was lots of memory, say 1GB. I'm not
sure why, but I suspect there is a siginificant overhead to lookup
shared buffers.
--
Tatsuo Ishii