Date: Mon, 10 Oct 2005 19:29:37 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Jon Brisbin <jon.brisbin@npcinternational.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Performance on SUSE w/ reiserfs
Message-ID: <20051010222937.GL5848@surnet.cl>
Mail-Followup-To: Jon Brisbin <jon.brisbin@npcinternational.com>,
	pgsql-performance@postgresql.org
References: <434ADD46.5060206@npcinternational.com>
	<6247.1128981289@sss.pgh.pa.us>
	<434AE7FF.4000705@npcinternational.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <434AE7FF.4000705@npcinternational.com>
User-Agent: Mutt/1.5.10i

Jon Brisbin wrote:
> Tom Lane wrote:
> >
> >Are you sure it's not cached data pages, rather than cached inodes?
> >If so, the above behavior is *good*.
> >
> >People often have a mistaken notion that having near-zero free RAM means
> >they have a problem.  In point of fact, that is the way it is supposed
> >to be (at least on Unix-like systems).  This is just a reflection of the
> >kernel doing what it is supposed to do, which is to use all spare RAM
> >for caching recently accessed disk pages.  If you're not swapping then
> >you do not have a problem.
> 
> Except for the fact that my Java App server crashes when all the 
> available memory is being used by caching and not reclaimed :-)

Ah, so you have a different problem.  What you should be asking is why
the appserver crashes.  You still seem to have a lot of free swap,
judging by a nearby post.  But maybe the problem is that the swap is
completely used too, and so the OOM killer (is this Linux?) comes around
and kills the appserver.

Certainly the problem is not the caching.  You should be monitoring when
and why the appserver dies.

-- 
Alvaro Herrera                         Architect, http://www.EnterpriseDB.com
"On the other flipper, one wrong move and we're Fatal Exceptions"
(T.U.X.: Term Unit X  - http://www.thelinuxreview.com/TUX/)