Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Tomcat dies suddenly

Trying to diagnose some bizarre Tomcat (7.0.21) and/or JVM errors on a 64-bit linux (CentOS) machine.

I'm load testing our server application and tried hitting it with 100K messages. Launched jvisualvm and kept my eye on the heap the whole time. Everything was looking great* (see below) until I got to about 93K processed messages and then Tomcat just died. Ran a ps on Tomcat's PID number to confirm it was dead.

Up until this crash:

  • Load test had been running for about 90 minutes; should have finished shortly thereafter since we were at 93K/100K)
  • CPU was holding strong around 45%
  • Used heap was around 2GB (plus or minus a bunch after GCs) but heap size grew from 4GB to MAX_HEAP after about 30 minutes
  • Class loading/unloading was cycling normally
  • Thread dumps were normal

Nowhere in the server code are any calls to System.exit() - so we can rule that right out (and yes I've double-checked!!!).

I'm not sure if this is Tomcat crashing or the JVM (how do I tell?). And even if I did know, I can't seem to find any indication of what went wrong:

  • All of the server app's logs just stop without any ERROR messages (even though we have logging universally set to DEBUG and higher)
  • Tomcat's catalina.out and respect localhost_access_* files just stop without any info

I've heard it is possible to have Tomcat log a coredump when it does but not sure how to do that and online examples aren't helping much.

How would SO go about diagnosing this? What steps should I take to start ruling out all of the possible factors?

Thanks in advance!

like image 312
IAmYourFaja Avatar asked Feb 03 '12 17:02

IAmYourFaja


2 Answers

If the JVM crashes, you should have a hs_err_pidNNN.log file; you don't have to do anything to enable this. Its location depends on your OS and how you are running Tomcat. On Windows, they can show up on your desktop, unless you are running as a service. Otherwise, they should be in the current working directory of the crashed process.

Your operating system probably provides additional tools for process monitoring; you could describe your environment more, or perhaps ask at serverfault.com.

It's also possible that jvisualvm is actually causing the crash.

I'd try reproducing the problem, and progressively simplify the scenario to help isolate the cause.

like image 168
erickson Avatar answered Sep 20 '22 18:09

erickson


Another possibility is that the OS is running out of memory and the OOM Killer is killing your process. In this case, the JVM wouldn't get an opportunity to write a heap dump, or an hs_err_pid file.

like image 44
dty Avatar answered Sep 18 '22 18:09

dty