My Tomcat Crashing

[Garrett Smith]

OOME. F. I have no idea.

How do I troubleshoot OutOfMemoryError?

All I know is: Tomcat is down, I restart it. IT's up. IT WILL crash again. Sometime.

I have several OOME's in the logfile, I guess I should go w/the 1st? What can I use to profile my app running remotely on DailyRazor servers?

[Ilja Preuss]

The Stacktrace of an OOME doesn't really help that much, because it just tells you when the stack was full, not what caused it to fill up over time.

You need to find out about which objects don't get garbage collected, though they should - and why. A good commercial profiler for this task is JProfiler - can't tell you about free ones, sorry.

[William Brogden]

Recall that there are methods in the java.lang.Runtime class that let you get at current memory useage. You could write these values to a log file or even create a servlet or JSP to display them in HTML.

It is also possible that even with correct memory management code, a number of "simultaneous" requests could exceed the allocated memory. What facilities for memory configuration does "DailyRazor" provide?

Bill

[Peter Chase]

Originally posted by William Brogden:
Recall that there are methods in the java.lang.Runtime class that let you get at current memory useage.

There are, but they are mostly useless.

Runtime.freeMemory() tells you how much heap is free, but when freeMemory() is low you can't tell whether it is full of reclaimable dead objects (and hence perfectly healthy) or live objects (and hence in trouble). Also, I seem to remember that totalMemory() doesn't give the figure you expect, either.

You need a memory profiler.

[Garrett Smith]

Originally posted by William Brogden:

It is also possible that even with correct memory management code, a number of "simultaneous" requests could exceed the allocated memory. What facilities for memory configuration does "DailyRazor" provide?

I asked about increasing PermGen space, but they don't offer that option.

The only option, they say, is to upgrade to a dedicated server.

DailyRazor support:
PermGen space is always limited to 64Mb, this is a hard limit that will not be overriden. If your application require more PermGen space you should upgrade to dedicated server, where you will be able to have as much space as you like.

In any case, this issue has nothing to do with server itself, it's only your application that require too much memory to run, so basically you have only these choices: 1. Somehow optimise your application to use less classes and libraries or 2. Upgrade to dedicated server.

Wow, so I can upgrade to a dedicated server. $3000 USD/year. Yeah, OK. That sounds reasonable for a personal website.

I'm looking into JProfiler to see if and how I can run it remotely.

[Ernest Friedman-Hill]

Where did you get the idea that it's the permanent generation that is running out of memory? That area is used for interned Strings, class and method components; it's not used for most of your application data, and 64MB should generally be more than enough.

[Garrett Smith]

I got that idea from the stack trace:

[dhtmlkitchen.com].[/manager] - HTMLManager: restart: Reloading web application at '/'
INFO TP-Processor52485 org.apache.catalina.core.StandardContext - Reloading this Context has started
ERROR TP-Processor52485 org.apache.catalina.session.ManagerBase - Exception unloading sessions to persistent storage
java.lang.OutOfMemoryError: PermGen space
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
at java.lang.Class.getDeclaredMethod(Class.java:1935)
at java.io.ObjectStreamClass.getPrivateMethod(ObjectStreamClass.java:1382)
...

[Ernest Friedman-Hill]

Ah! OK, now we're getting somewhere. Read this, my friend:

http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java

Looks very much like what's happening is that your app is handing out references to some of its objects, so that when it is reloaded/redeployed those object persist and prevent the old classes from being collected.

[Garrett Smith]

Originally posted by Ernest Friedman-Hill:
Ah! OK, now we're getting somewhere. Read this, my friend:

http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
Thanks for that article.

Looks very much like what's happening is that your app is handing out references to some of its objects, so that when it is reloaded/redeployed those object persist and prevent the old classes from being collected.

I get the same symptoms described in that article.

I changed my log4j.properties.
FROM:
log4j.rootLogger=DEBUG, stdout
TO:
log4j.rootLogger=ERROR, stdout

Had no effect.

I contacted the JProfiler folks to see if I could run the profiler remotely. No reply yet. I might have to suck it up and pay the $200 for this.

[Garrett Smith]

DailyRazor Support

Dear Customer,

Your application was overloading the server, we had to stop your tomcat. You can start it at any time, however if we will notice that it's consuming too much of server resources we will suspend your account.

Thank you.

I guess should say, "you're welcome?"

What the hell?

[Ilja Preuss]

Originally posted by Garrett Smith:

I contacted the JProfiler folks to see if I could run the profiler remotely.

You can. The connection wizard is quite good - you tell it what you want to do and how your server is configured, and it will create a configuration and tell you what manual steps you need to do.

[Jim Yingst]

Well, that seems consistent with EFH's previous diagnosis. If you keep creating new objects and the server is unable to GC them, eventually memory will run out. I'm guessing that memory is the particular "resource" referred to in the e-mail you received. You should probably try to debug this problem on a locally-run instance of Tomcat. If you keep running the buggy version on your provider's server, you'll just tick them off more.

[Garrett Smith]

Originally posted by Ilja Preuss:


You can. The connection wizard is quite good - you tell it what you want to do and how your server is configured, and it will create a configuration and tell you what manual steps you need to do.

DailyRazor that I won't be able to use JProfiler on their servers because they use jsvc instead of java, and that most command-line options needed for JProfiler are not implemented in jsvc. Is this true?

They go on to tell me that I should be using JBoss.

The hosted site has 30-80 sessions at any given time and the environment is different than my local env. I can just try JProfiler locally and hope for the best.

[Ernest Friedman-Hill]

Note that the article I linked to uses the logging stuff as an example of a general principle; there are lots of other ways that you could be causing the same problem. Look through the codebase for places where you're handing an instance of one of your classes off to any 3rd-party API, then investigate those cases. As Jim suggests, debugging locally is a good idea -- although unfortunately if you don't replicate the server environment closely enough -- especially which loaders load which libraries -- the bug might not manifest.

[Shuaib Asekome]

please i want java code for solving gauuss jordan iteration

[Jim Yingst]

Which has absolutely nothing to do with anything in this thread. Please start a new post for such an unrelated topic. Also, people here aren't inclined to do you homework for you. I suggest you read How To Ask Questions on JavaRanch as a good starting point.

[Garrett Smith]

You guys are awesome! Thanks.

I think, it *might* be Tiles. All the JSPs are slow except the ones that do not use Tiles.

Example:
1. 4.7k, no Tiles, load-time < 2sec
http://dhtmlkitchen.com/learn/js/enumeration/example/datedcard.jsp

2. 4.2k, Tiles used, load-time > 8sec
http://dhtmlkitchen.com/learn/js/enumeration/set-dontenum.jsp

Now I'm guessing (this is only a guess), that if Tiles pages are slow, maybe Tiles is doing a heavy operation that causes more memory use, possibly handing out references. If this is true, then running JProfiler @ home will reveal it.
[ October 21, 2007: Message edited by: Garrett Smith ]