Howdy, I would suggest profiling just your application, if possible, without a web server at all. Alternatively, run the web server with a profiler (OptimizeIt, JProbe, etc.) and try to allocate memory leaks. The profiler will show tomcat classes as well, so you can try to look for memory leaks there, but I doubt you'd find any.
When profiling, be careful not to do it on your production server, as running with a profiler will slow things down a whole lot. As a side note: JDK 1.1.7 is really old. You app may greatly benefit from taking advantage of some of the newer features available in JDK 1.4. Yoav Shapira Millennium ChemInformatics >-----Original Message----- >From: Dov Rosenberg [mailto:[EMAIL PROTECTED] >Sent: Wednesday, March 05, 2003 4:24 PM >To: Tomcat Users List >Subject: Re: Tomcat 4.1.18: 500+ Servlets locks up on Solaris under load > >I'm not sure if Tomcat is totally to blame, I'm sure when I figure out >the problem it will point to our code. > >The reason I suspect Tomcat at this point is when the app is not under >load (i.e. using Jmeter to simulate 10-20 user concurrent load) the app >seems OK. the response times are acceptable even under as long as a >servlet doesn't retrieve a lot of data. (I didn't write the app, just >trying to fix it). The app is running fairly well under JDK 1.17 on >Java WebServer on NT but falls on its knees under JDK 1.3.0 and Tomcat >4.1.18. > >We have done a bunch of other things on Tomcat (not 4.1.18) without >having this kind of behavior. > >Dov Rosenberg > >On Wednesday, March 5, 2003, at 04:10 PM, Shapira, Yoav wrote: > >> >> Howdy, >> Given >> "once a servlet >> loads that retrieves a bunch of data, the CPU processing starts to >> increase until it pegs at 99% (according to TOP). All users then stop >> responding. The only way to recover is to terminate the process and >> restart Tomcat. The garbage collection indicates when the app becomes >> unresponsive the garbage collection shows a lot of full garbage >> collection cycles but the app never recovers - it essentially goes into >> an endless loop." >> what makes you think this is a tomcat problem, as opposed to for >> example >> a loop in your app or a memory leak in your app? >> >> Yoav Shapira >> Millennium ChemInformatics >> >> >>> -----Original Message----- >>> From: Dov Rosenberg [mailto:[EMAIL PROTECTED] >>> Sent: Wednesday, March 05, 2003 3:57 PM >>> To: [EMAIL PROTECTED] >>> Subject: Tomcat 4.1.18: 500+ Servlets locks up on Solaris under load >>> >>> I have a Solaris server running Tomcat 4.1.18 and Java 1.3.0 with a >>> single CPU and 2GIG RAM. The application has 500+ servlets that were >>> originally developed under JDK 1.17b to run under the old Java Web >>> Server on Windows NT4. The old system seems to handle the load much >>> better than the new version. We have configured the Invoker to load >>> the >>> servlets automatically instead of explicitly naming them in the >> web.xml. >>> >>> I am launching the Tomcat server with the following parameters: >>> >>> -server -Xms384m -Xmx384m -XX:NewSize=128m -XX:MaxNewSize=128m >>> -Xconcurrentio -Xincgc -verbose:gc >>> >>> under load the Tomcat server runs fine for a bit but once a servlet >>> loads that retrieves a bunch of data, the CPU processing starts to >>> increase until it pegs at 99% (according to TOP). All users then stop >>> responding. The only way to recover is to terminate the process and >>> restart Tomcat. The garbage collection indicates when the app becomes >>> unresponsive the garbage collection shows a lot of full garbage >>> collection cycles but the app never recovers - it essentially goes >>> into >>> an endless loop. >>> >>> Some of the parameters in our server.xml are: >>> >>> <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" >>> redirectPort="443" bufferSize="2048" port="8009" connectionTimeout="0" >>> scheme="http" enableLookups="true" secure="false" >>> protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler" >>> debug="9" disableUploadTimeout="false" ProxyPort="0" >>> maxProcessors="75" >>> minProcessors="5" tcpNoDelay="true" acceptCount="10" >>> useURIValidationHack="false"> >>> <Factory >>> className="org.apache.catalina.net.DefaultServerSocketFactory"/> >>> </Connector> >>> >>> <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" >>> redirectPort="-1" bufferSize="2048" port="80" connectionTimeout="0" >>> scheme="http" enableLookups="true" secure="false" >>> protocolHandlerClassName="org.apache.coyote.http11.Http11Protocol" >>> debug="9" disable UploadTimeout="false" proxyPort="0" >>> maxProcessors="-1" minProcessors="5" tcpNoDelay="true" >>> acceptCount="10" >>> useURIValidationHack="true"> >>> <Factory >>> className="org.apache.catalina.net.DefaultServerSocketFactory"/> >>> </Connector> >>> >>> >>> I am running Tomcat on port 80 as the root user if that has any >>> bearing >>> on things. Originally we had Apache in the mix, but to simplify >>> figuring out the problems we have configured Tomcat to act as the web >>> server for the time being. Some of the static resource directories are >>> symbolic links. >>> >>> Dov Rosenberg >>> Conviveon Corporation >>> 407-339-1177 ext 102 >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> This e-mail, including any attachments, is a confidential business >> communication, and may contain information that is confidential, >> proprietary and/or privileged. This e-mail is intended only for the >> individual(s) to whom it is addressed, and may not be saved, copied, >> printed, disclosed or used by anyone else. If you are not the(an) >> intended recipient, please immediately delete this e-mail from your >> computer system and notify the sender. Thank you. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
