Pieter Temmerman wrote:
Try this strace command:
strace -f -etrace=\!futex,gettimeofday,clock_gettime -p
PID_OF_TOMCAT_JAVA
where PID_OF_TOMCAT_JAVA is the PID of your Tomcat, duh! :)
Thanks! That certainly did the trick. The first time I ran strace against the Tomcat process, it brought Tomcat to a
halt. I had to restart it.
After the restart, it took an absolute eternity for the sites to respond to requests, as usual. One thing that I
haven't mentioned, by the way, is that all four sites begin to respond at the SAME TIME. There appears to be something
going on server-wide that finally resolves. (There are currently four Host entries in server.xml, each of which having
several Context entries, by the way. Three hosts are on the same IP address, one has its own.)
During the startup stall phase, I requested my simple test JSP page. strace revealed, as it did for all the other pages
being requested on the server, repeated calls to stat64 and lstat64 of the SAME class files. Here are the lines from
strace while test6.jsp (precompiled into test6_jsp.class) was stalled:
http://www.ims.net/media/strace-test6-stall.txt
After I shut off strace (being convinced that it was hindering the server from getting done with its post-startup
shenanigans), and the rest of the sites were finally responding to requests, I fired up strace again and requested
test6.jsp, and got this:
http://www.ims.net/media/strace-test6-ok.txt
along with a successful HTTP response. So: stat64; access; lstat64; stat64; read; read; read. The class probably was
already loaded from the previous stalled request.
During the Tomcat stall phase there are thousands and thousands of stat64, access, lstat64 calls to the same class files
(and directories above those files) across pages on all four sites.
My next step is to set up a new instance on another port so I (hopefully) stop beating on the production sites with
these diagnostics, and then do Mark's suggestion to import, one by one, the classes in my Java package to see if there
is a particular one that is causing the delay. I've tried that to some extent in the past and felt that the delay just
increased linearly as I added more classes, but I can do it more methodically.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
