tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Hokin <...@ims.net>
Subject Re: very slow class loading on initial JSP/servlet request after restart
Date Wed, 25 Feb 2009 18:31:54 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message