cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Joseph <pjos...@gmail.com>
Subject Re: scaling problem
Date Fri, 21 Oct 2011 13:52:14 GMT
Good point...I shall dig deeper.

One strange thing (or seemed strange to me) was that last night Tomcat 
Manager reported to me that I had used all 3.5 GB allocated to me.

This morning when I logged back in, it was saying the same thing (after 
I refreshed it).

I saw this happen once more during testing today i.e. after exhausting 
memory, and on leaving the server alone for over an hour, no memory was 
reclaimed even though the session time out was set to 20 minutes.

Yesterday was with the default garbage collector, today I used the new 
/Garbage-First Garbage Collector./

This is a AMD server running a Virtual Machine (64 bit Windows 2008, R2).

Should I be seeing this kind of behavior?

Paul

On 10/21/2011 9:27 AM, Mark H. Wood wrote:
> Well, "JVM runs out of memory" could have any of several meanings,
> because it has several different pools of memory and any one of them
> could have been exhausted.  You need more information.  Is it running
> out of heap, of PermGen, something else?  These answers will inform
> your search for the problem.
>
> Employ a monitoring tool (I use PsiProbe) and watch the memory
> behavior as you approach and hit the wall.
>
> You don't really run out of memory by having lots of garbage; your
> app.'s performance begins to "stutter" as GC occasionally becomes a
> larger part of the load.  No, you run out of memory by accumulating
> uncollectable objects -- they aren't recognized as garbage and so
> can't be reclaimed.  It may be that the design of your application
> requires such a large accumumlation, or it may be that it is leaking
> objects which are no longer useful but can't be collected because they
> are referenced by other objects which are still live.
>
> Because memory is organized in multiple pools, you can overfill one of
> them (and crash) while having plenty in the others.  It may be that
> you just need to redistribute the memory you have.  You'll need to
> continue monitoring and adjusting until you discover the necessary
> proportions, with each pool well filled yet having comfortable
> headroom for traffic spikes.
>
> BTW early in my Java work I found myself just throwing memory at such
> problems until they (sometimes) went away.  I eventually realized that
> it's possible to give a long-running Java app. *too much* memory --
> that a better approach is to keep the pools small enough that GC is
> somewhat frequent and never has a huge amount of garbage to deal
> with.  I don't want GC to run all the time, but neither do I want to
> see it going dormant for ages and then dominating for thousands of
> milliseconds.  I want each pool kept, on average, with free space in
> the minority but not too scanty.  Mostly what I want is that the main
> heap doesn't vary greatly in fill factor under steady load, which
> usually means that utilization is somewhat near maximum size but with
> room for occasional surges.
>
> Tweaking out unwelcome memory behavior takes a long time and a lot of
> staring and thinking.
>

Mime
View raw message