tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Tomcat caching
Date Mon, 16 Nov 2015 21:25:39 GMT

On 11/16/15 10:08 AM, David E. Filip wrote:
> None of those numbers alarming, unless you see Eden regularly
> increase beyond 90% and stay there, especially when you are seeing
> slowness, as then you might want to consider increasing your heap.
> In my view — and others may disagree! — understanding tuning JVM heap
> is more of an art than a science.

Erm, Eden should routinely "fill-up". That's what causes small GCs to
occur. Small GCs are no big deal. It's the big ones that can be a
problem. Most objects will die in Eden after being used for a very short
period of time -- like during a single request. Those that survive past
a small GC are tenured to older generations, presumably because they
will live a while longer.

> From the 30K foot view, objects get created in Eden (previously
> called NewGen I believe), then get moved to OldGen by the GC when
> they are still referenced after a certain period of time, and finally
> get moved to Survivor when if they are still referenced even later.

Big GCs happen when those older generations start to fill up. So
watching Eden is a waste of time. Watch "PS Old" and "PS Perm" for the
parallel, generational GC (which is the default for Java 1.7 and Java
1.8). The G1 collector has similar spaces which you can watch.

> However, when you say ‘developing’, if the problem is only when you
> are editing JSP pages — which Jasper then needs to recompile — or
> when performing new webapp deployments, I would also keep an eye on
> PermGen, which gets used when instantiating new static objects (as I
> understand it).  I have seen “weird” things happen when PermGen fills
> up, including seeing the server stop responding to certain requests,
> JSP pages not compiling, or “class not found” errors on the compiled
> JSP classes (org.apache.jsp.*).

The permanent generation is used for java.lang.Class objects and, for a
while, it was used for String.intern(). Statics have nothing to do with
it. Newer JVMs don't even have a "perm gen" because it's such a bad idea
with a properly-tuned garbage collector (and older GCs were anything but

> Of course, when either the heap or PermGen runs out, then you will
> start seeing a stack trace.  However, in my experience, there is this
> grey area between when you are almost out of memory but not quite
> yet.
> The caveat to all of this, however, is that everything gets cleared
> out when you restart the server.  And that is one of the ways to tell
> if that is indeed the problem, is when everything starlings running
> correctly right after a server restart.  However, if you are not
> seeing everything clear up after a clean restart of Tomcat, then I’m
> afraid this is not your problem.

Konstantin was suggesting that the OP intentionally generate a thread
dump during periods of "slowness". This will tell you what the server is
actually doing, so you don't have to ask the question "why is this
taking so long?" -- you can just observe what is taking so long.


> On Nov 16, 2015, at 9:48 AM, Daniel Küppers <>
> wrote:
>> Am 16.11.2015 um 14:56 schrieb David E. Filip:
>>> In my experience, the most common explanation (but certainly not
>>> the only!) for an active webapp to be occasionally and
>>> sporadically running extremely slow, but run fine at other times,
>>> is running low on heap space.
>>> If you have not already, I would suggest checking the Tomcat
>>> Server Status app (http://localhost:8080/manager/status) and
>>> determine if any of the heaps are filling up while you are
>>> experiencing this slowness.  If they are, your app could be
>>> spending too much time waiting for the garbage collector, and you
>>> will need to increase the heap size in your startup file.
>>> On Nov 16, 2015, at 6:45 AM, Konstantin Kolinko
>>> <> wrote:
>>>> 2015-11-16 12:22 GMT+03:00 Daniel Küppers
>>>> <>:
>>>>> Hi, i have a recurring issue, that tomcat caches my jsf
>>>>> webapp pages in a strange manner. Sometimes for multiple
>>>>> days/hours, one or two explict pages or the whole webapp is
>>>>> loading very slowly. My setup is a locally used tomcat 8.0.28
>>>>> for debugging in Eclipse and a local database. The behaviour
>>>>> persists also after browser cache clearing and with
>>>>> different browsers. Does anyone else have seen this behaviour
>>>>> before? Do i miss a specific parameter?
>>>> Your problem is "one or two explict pages or the whole webapp
>>>> is loading very slowly".  Why are you blaming caching?
>>>> Stack trace when application behaves slowly =? Is it know what
>>>> it actually does at that time?
>>>> Is the clock on your server set correctly? Is autoDeploy tuned
>>>> off on a Host, or it wastes time checking for changes of a war
>>>> file? Is Jasper (JspServlet) configured with development=false,
>>>> or it wastes time checking and recompiling the pages?
>>>> ---------------------------------------------------------------------
To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> Thanks for the replies. I will monitor the free heapspace from now
>> on. If i see something that concludes to this problem, i'll let you
>> know. For which exact Memory Pool i should have a watchout? Here
>> are my current used loads: - PS Eden Space: 89% - PS Old Gen: 4% -
>> PS Survivor Space: 33% I dont get a stacktrace when the app runs
>> slowly. I also only get this issues when the configuration is in
>> developing mode. It persists even restarts. Clock is set correctly,
>> AutoDeploy is On, running in development mode (myFaces). I cant
>> determine how Jasper should be configured.
>> Daniel
>> ---------------------------------------------------------------------
To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message