Re: Performance on SUSE w/ reiserfs - Mailing list pgsql-performance

From Alex Turner
Subject Re: Performance on SUSE w/ reiserfs
Date
Msg-id 33c6269f0510110727q62a797a1g9493661e1dc905d4@mail.gmail.com
Whole thread Raw
In response to Re: Performance on SUSE w/ reiserfs  (Jon Brisbin <jon.brisbin@npcinternational.com>)
Responses Re: Performance on SUSE w/ reiserfs
List 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.brisbin@npcinternational.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@postgresql.org so that your
       message can get through to the mailing list cleanly

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Massive delete performance
Next
From: "Andy"
Date:
Subject: Re: Massive delete performance