Re: Performance on SUSE w/ reiserfs

From: Alex Turner <armtuk(at)gmail(dot)com>
To: Jon Brisbin <jon(dot)brisbin(at)npcinternational(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance on SUSE w/ reiserfs
Date: 2005-10-11 14:27:36
Message-ID: 33c6269f0510110727q62a797a1g9493661e1dc905d4@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Realise also that unless you are running the 1.5 x86-64 build, java will not
use more than 1Gig, and if the app server requests more than 1gig, Java will
die (I've been there) with an out of memory error, even though there is
plenty of free mem available. This can easily be cause by a lazy GC thread
if the applicaiton is running high on CPU usage.

The kernel will not report memory used for caching pages as being
unavailable, if a program calls a malloc, the kernel will just swap out the
oldest disk page and give the memory to the application.

Your free -mo shows 3 gig free even with cached disk pages. It looks to me
more like either a Java problem, or a kernel problem...

Alex Turner
NetEconomist

On 10/10/05, Jon Brisbin <jon(dot)brisbin(at)npcinternational(dot)com> 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 :-)
>
> If it wasn't for the app server going down, I probably wouldn't care.
>
> --
>
> Jon Brisbin
> Webmaster
> NPC International, Inc.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Andy 2005-10-11 14:27:40 Re: Massive delete performance
Previous Message Tom Lane 2005-10-11 14:17:12 Re: Massive delete performance