b.henr...@pepperone.be wrote: > We have sometimes Tomcat (5.x) who consume all the CPU (or 50 %) of the > CPU constantly in our productions servers (Linux or Windows).
Adding to the thread dump mentioned by Leon, on Linux you can run "ps -fLp <tomcat_pid>" to see CPU time usage per thread. Running this twice in a row (with f.ex. 10 second interval) should show you which of the threads is consuming the CPU (supposing it's just a single thread). Combining this with the stack dumps form "kill -QUIT" should help you pinpoint the bad thread. > Our applications aren't doing anything and the only solution is to > restart Tomcat. That sounds like a deadlock of some kind (or it could also be JVM memory exhaustion, in which case you should see the garbage collector thread as the one taking up the CPU). Both could well be caused by the code you run on Tomcat. > However, we set heap (between 1GO and 2GO) like this: Xmx = Xms < > [physical memory available] when the server starts, so Tomcat shouldn't > have disk swapping problem. (Am I wrong?) But other services can eat the > memory and the server can begin to swap... Regardless of Xms/Xmx the OS could well choose to page parts of the Java process to disk, if there's OS level memory shortage. By setting Xms and Xmx equal you simplify the JVM internal memory management (no need to run the logic do decide whether the overall memory allocation should be increased or decreased, and apparently a number of other memory handling checks, too). So, with this configuration there's just one, fixed, memory allocation limit for JVM. -- ..Juha --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
