Re: Tomcat performance issue?
I'm sending my JVM stack trace to see if any of you are better at reading it than I am. ;-) I'm guessing that you can somehow tell by looking at the stack trace whether the connections between apache and tomcat are somehow being held onto or locked waiting for something and not released. Maybe a database connection is not released? Maybe apache graceful causes the problem? Any input is appreciated. Thanks for your help! apache version 2.0.40 mod_jk 2.0.2 tomcat 4.1.27 and 4.1.30 I've attached the javacore file (I stripped out classloader lines since they take up the majority of the file) Let me know if you need to see those. Daniel Gibby David Rees wrote: Daniel Gibby wrote: Tomcat config: Connector className="org.apache.catalina.connector.http.HttpConnector" port="8080" minProcessors="5" maxProcessors="255" enableLookups="true" redirectPort="8443" acceptCount="100" debug="0" connectionTimeout="6"/ Hey, I just realized something... I think I have been having lockups around every 16 hours... 6 seconds! So what does that mean about this configuration? connectionTimeout is defined in milliseconds, not seconds, so that is 60 seconds, not 16 hours. Is some servlet not returning content but hanging on to a connection? Could be, or could be that your server is really busy. When you look at the server-status through Apache, does it show 255 processes busy as well? Could you explain a little further about 'bug in a servlet causing it to not return'? You could either have a deadlock (synchronization issue) in your code, or an infinite loop. I have a stack trace, but I don't see how that helps me figure out where my problem might be... I'm not sure what exactly to look for. Compress it and post it to the list or put it on a public webserver so we can take a look. Cheers Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] javacore.20040413.36.23498-short.txt.gz Description: application/gzip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat performance issue?
Hi, Absolutely. Peter and I have been preaching this for years now ;) I'm glad this has helped you... Yoav Shapira Millennium Research Informatics -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Monday, April 12, 2004 10:17 PM To: Tomcat Users List Subject: RE: Tomcat performance issue? glad the suggestion helps. I firmly believe in profiling code to make sure simple little mistakes that appear harmless aren't killing performance. I'm constantly amazed at how little things improve performance. the benefit of using OptimizeIt or any other good profiling tool is well worth it. that's my biased perspective :) peter lin --- Allistair Crossley [EMAIL PROTECTED] wrote: This evening I did the same with JProbe under 360 requests as you describe and this led to me gaining a 38% speedup. The main bottleneck I found was some very simple tags I have were calling out.flush() at the end. Thiw was consuming 14 seconds of time to flush 1 string from the tag. The tag is called many times within our JSPs because it calls the current skin label. By simply removing the flush call the tag call method time across the load test went down to 2s. Not bad hey. There were other areas which I solved with application scope caching and a bean pool for a 3rd party bean that takes ages to initialise a connection. I am getting there slowly but surely but Yoav I think was right all along and it is the code and you have to profile it and examine those call graphs!!! ADC -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Mon 12/04/2004 19:53 To: Tomcat Users List Cc: Subject: Re: Tomcat performance issue? luckily I have a license of Borland OptimizeIt. What I do is I start tomcat using OptimizeIt. Then I create a test plan in JMeter. Once tomcat is running, I warm it up by sending it a couple hundred requests to make sure all the pages are compiled. before the test starts, use OptimizeIt to garbage collect. Once that is done, I start the test and look at the number of threads and size of the heap. If there's a memory leak, either the thread count will increase, or the heap will grow rapidly. Once I see either one, I then switch to the call graph to get a better picture of which methods are getting called. Usually, that is enough to point towards a culprit. repeat, and rinse as many times as needed until you've squashed all bugs and leaks. peter lin Matt Woodings [EMAIL PROTECTED] wrote: I just read your post this morning (I am lurking today as I have a few issues of my own to clear up :-) ) and I think that is some really good advice you gave. I do have a question though. Once you have noticed you have a memory leak, how do you go about locating it? Matt - Do you Yahoo!? Yahoo! Tax Center - File online by April 15th FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE --- QAS Ltd. Developers of QuickAddress Software a href=http://www.qas.com;www.qas.com/a Registered in England: No 2582055 Registered in Australia: No 082 851 474 --- /FONT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ - 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]
Re: Tomcat performance issue?
I have this same problem. It creeped up without any configuration changes on 4.1.27 It doesn't always print this error message out, but the effect is the same. SEVERE: All threads (75) are currently busy, waiting. Increase maxThreads (75) or check the servlet status My apache config: Timeouts: connection: 300keep-alive: 300 MPM Name: Prefork MPM Information: Max Daemons: 255 Threaded: no Forked: yes IfModule prefork.c StartServers 8 MinSpareServers5 MaxSpareServers 20 MaxClients 255 MaxRequestsPerChild 1000 /IfModule Tomcat config: Connector className=org.apache.catalina.connector.http.HttpConnector port=8080 minProcessors=5 maxProcessors=255 enableLookups=true redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=6/ Hey, I just realized something... I think I have been having lockups around every 16 hours... 6 seconds! So what does that mean about this configuration? Why is the connectionTimeout being reached? I think I had set it to a really high number because I figured I didn't want anything to ever hit it. Is some servlet not returning content but hanging on to a connection? Could you explain a little further about 'bug in a servlet causing it to not return'? I have a stack trace, but I don't see how that helps me figure out where my problem might be... I'm not sure what exactly to look for. Daniel Gibby David Rees wrote: Like the messages say, all Tomcat threads are busy and you've hit the maximum number of threads which can be processed concurrently. Sounds like you've got either a bug in a servlet causing it to not return, or your server is simply overloaded. You can get a stack trace from the JVM to help debug this issue pretty easily. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance issue?
I forgot to mention that I have All threads (255) are currently busy, not (75) which makes sense. Daniel Gibby wrote: I have this same problem. It creeped up without any configuration changes on 4.1.27 It doesn't always print this error message out, but the effect is the same. SEVERE: All threads (75) are currently busy, waiting. Increase maxThreads (75) or check the servlet status My apache config: Timeouts: connection: 300keep-alive: 300 MPM Name: Prefork MPM Information: Max Daemons: 255 Threaded: no Forked: yes IfModule prefork.c StartServers 8 MinSpareServers5 MaxSpareServers 20 MaxClients 255 MaxRequestsPerChild 1000 /IfModule Tomcat config: Connector className=org.apache.catalina.connector.http.HttpConnector port=8080 minProcessors=5 maxProcessors=255 enableLookups=true redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=6/ Hey, I just realized something... I think I have been having lockups around every 16 hours... 6 seconds! So what does that mean about this configuration? Why is the connectionTimeout being reached? I think I had set it to a really high number because I figured I didn't want anything to ever hit it. Is some servlet not returning content but hanging on to a connection? Could you explain a little further about 'bug in a servlet causing it to not return'? I have a stack trace, but I don't see how that helps me figure out where my problem might be... I'm not sure what exactly to look for. Daniel Gibby David Rees wrote: Like the messages say, all Tomcat threads are busy and you've hit the maximum number of threads which can be processed concurrently. Sounds like you've got either a bug in a servlet causing it to not return, or your server is simply overloaded. You can get a stack trace from the JVM to help debug this issue pretty easily. - 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]
RE: Tomcat performance issue?
It could be a bug in your servlet that hangs your connection or you might actually have a big enough load to max out your number of concurrent Tomcat threads (maxProcessors). If it is load, you should look into increasing your maxProcessors. Make sure though that you have enough JVM heap memory (Xmx parm) to handle it or you will run into OutOfMemory error which is worse than out-of-connections. Jason -Original Message- From: Daniel Gibby [mailto:[EMAIL PROTECTED] Sent: Monday, April 12, 2004 9:43 AM To: Tomcat Users List Subject: Re: Tomcat performance issue? I have this same problem. It creeped up without any configuration changes on 4.1.27 It doesn't always print this error message out, but the effect is the same. SEVERE: All threads (75) are currently busy, waiting. Increase maxThreads (75) or check the servlet status My apache config: Timeouts: connection: 300keep-alive: 300 MPM Name: Prefork MPM Information: Max Daemons: 255 Threaded: no Forked: yes IfModule prefork.c StartServers 8 MinSpareServers5 MaxSpareServers 20 MaxClients 255 MaxRequestsPerChild 1000 /IfModule Tomcat config: Connector className=org.apache.catalina.connector.http.HttpConnector port=8080 minProcessors=5 maxProcessors=255 enableLookups=true redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=6/ Hey, I just realized something... I think I have been having lockups around every 16 hours... 6 seconds! So what does that mean about this configuration? Why is the connectionTimeout being reached? I think I had set it to a really high number because I figured I didn't want anything to ever hit it. Is some servlet not returning content but hanging on to a connection? Could you explain a little further about 'bug in a servlet causing it to not return'? I have a stack trace, but I don't see how that helps me figure out where my problem might be... I'm not sure what exactly to look for. Daniel Gibby David Rees wrote: Like the messages say, all Tomcat threads are busy and you've hit the maximum number of threads which can be processed concurrently. Sounds like you've got either a bug in a servlet causing it to not return, or your server is simply overloaded. You can get a stack trace from the JVM to help debug this issue pretty easily. - 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]
Re: Tomcat performance issue?
255 is as high as apache will go without recompiling. Therefore, it wouldn't make a difference if I go higher on the tomcat end either, right? Trieu, Jason T - CNF wrote: It could be a bug in your servlet that hangs your connection or you might actually have a big enough load to max out your number of concurrent Tomcat threads (maxProcessors). If it is load, you should look into increasing your maxProcessors. Make sure though that you have enough JVM heap memory (Xmx parm) to handle it or you will run into OutOfMemory error which is worse than out-of-connections. Jason -Original Message- From: Daniel Gibby [mailto:[EMAIL PROTECTED] Sent: Monday, April 12, 2004 9:43 AM To: Tomcat Users List Subject: Re: Tomcat performance issue? I have this same problem. It creeped up without any configuration changes on 4.1.27 It doesn't always print this error message out, but the effect is the same. SEVERE: All threads (75) are currently busy, waiting. Increase maxThreads (75) or check the servlet status My apache config: Timeouts: connection: 300keep-alive: 300 MPM Name: Prefork MPM Information: Max Daemons: 255 Threaded: no Forked: yes IfModule prefork.c StartServers 8 MinSpareServers5 MaxSpareServers 20 MaxClients 255 MaxRequestsPerChild 1000 /IfModule Tomcat config: Connector className=org.apache.catalina.connector.http.HttpConnector port=8080 minProcessors=5 maxProcessors=255 enableLookups=true redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=6/ Hey, I just realized something... I think I have been having lockups around every 16 hours... 6 seconds! So what does that mean about this configuration? Why is the connectionTimeout being reached? I think I had set it to a really high number because I figured I didn't want anything to ever hit it. Is some servlet not returning content but hanging on to a connection? Could you explain a little further about 'bug in a servlet causing it to not return'? I have a stack trace, but I don't see how that helps me figure out where my problem might be... I'm not sure what exactly to look for. Daniel Gibby David Rees wrote: Like the messages say, all Tomcat threads are busy and you've hit the maximum number of threads which can be processed concurrently. Sounds like you've got either a bug in a servlet causing it to not return, or your server is simply overloaded. You can get a stack trace from the JVM to help debug this issue pretty easily. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance issue?
Daniel Gibby wrote: Tomcat config: Connector className=org.apache.catalina.connector.http.HttpConnector port=8080 minProcessors=5 maxProcessors=255 enableLookups=true redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=6/ Hey, I just realized something... I think I have been having lockups around every 16 hours... 6 seconds! So what does that mean about this configuration? connectionTimeout is defined in milliseconds, not seconds, so that is 60 seconds, not 16 hours. Is some servlet not returning content but hanging on to a connection? Could be, or could be that your server is really busy. When you look at the server-status through Apache, does it show 255 processes busy as well? Could you explain a little further about 'bug in a servlet causing it to not return'? You could either have a deadlock (synchronization issue) in your code, or an infinite loop. I have a stack trace, but I don't see how that helps me figure out where my problem might be... I'm not sure what exactly to look for. Compress it and post it to the list or put it on a public webserver so we can take a look. Cheers Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance issue?
From my own experience, this kind of behavior appears when a session isn't getting timed out for one reason or another. For example, say you get data from some remote site using your own Http client libraries that is multi-threaded. If that thread sits around and the socket it has isn't explicitly closed, it can prevent tomcat from invalidating the session. this would create a memory leak which may not be noticeable if you don't get a lot of load. One easy way to expose this kind of bug is to load test your webapp before deploying. Throw the load you get in 16 hrs at tomcat and you'll likely see the memory leak. In all cases, issues with performance was due to a bug in our application. egular load testing is the best way to expose these issues during development. peter David Rees [EMAIL PROTECTED] wrote: Daniel Gibby wrote: Tomcat config: className=org.apache.catalina.connector.http.HttpConnector port=8080 minProcessors=5 maxProcessors=255 enableLookups=true redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=6/ Hey, I just realized something... I think I have been having lockups around every 16 hours... 6 seconds! So what does that mean about this configuration? connectionTimeout is defined in milliseconds, not seconds, so that is 60 seconds, not 16 hours. Is some servlet not returning content but hanging on to a connection? Could be, or could be that your server is really busy. When you look at the server-status through Apache, does it show 255 processes busy as well? Could you explain a little further about 'bug in a servlet causing it to not return'? You could either have a deadlock (synchronization issue) in your code, or an infinite loop. I have a stack trace, but I don't see how that helps me figure out where my problem might be... I'm not sure what exactly to look for. Compress it and post it to the list or put it on a public webserver so we can take a look. Cheers Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! Tax Center - File online by April 15th
Re: Tomcat performance issue?
I just read your post this morning (I am lurking today as I have a few issues of my own to clear up :-) ) and I think that is some really good advice you gave. I do have a question though. Once you have noticed you have a memory leak, how do you go about locating it? Matt - Original Message - From: Peter Lin [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Monday, April 12, 2004 1:07 PM Subject: Re: Tomcat performance issue? From my own experience, this kind of behavior appears when a session isn't getting timed out for one reason or another. For example, say you get data from some remote site using your own Http client libraries that is multi-threaded. If that thread sits around and the socket it has isn't explicitly closed, it can prevent tomcat from invalidating the session. this would create a memory leak which may not be noticeable if you don't get a lot of load. One easy way to expose this kind of bug is to load test your webapp before deploying. Throw the load you get in 16 hrs at tomcat and you'll likely see the memory leak. In all cases, issues with performance was due to a bug in our application. egular load testing is the best way to expose these issues during development. peter David Rees [EMAIL PROTECTED] wrote: Daniel Gibby wrote: Tomcat config: className=org.apache.catalina.connector.http.HttpConnector port=8080 minProcessors=5 maxProcessors=255 enableLookups=true redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=6/ Hey, I just realized something... I think I have been having lockups around every 16 hours... 6 seconds! So what does that mean about this configuration? connectionTimeout is defined in milliseconds, not seconds, so that is 60 seconds, not 16 hours. Is some servlet not returning content but hanging on to a connection? Could be, or could be that your server is really busy. When you look at the server-status through Apache, does it show 255 processes busy as well? Could you explain a little further about 'bug in a servlet causing it to not return'? You could either have a deadlock (synchronization issue) in your code, or an infinite loop. I have a stack trace, but I don't see how that helps me figure out where my problem might be... I'm not sure what exactly to look for. Compress it and post it to the list or put it on a public webserver so we can take a look. Cheers Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! Tax Center - File online by April 15th - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat performance issue?
Hi, Once you have noticed you have a memory leak, how do you go about locating it? You don't just notice it out of the blue: you typically notice it because a profiler shows it. The same profiler shows you where it is. Noticing and locating is typically one and the same for memory leaks. It's fixing that's the 2nd step. Yoav Shapira 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]
Re: Tomcat performance issue?
luckily I have a license of Borland OptimizeIt. What I do is I start tomcat using OptimizeIt. Then I create a test plan in JMeter. Once tomcat is running, I warm it up by sending it a couple hundred requests to make sure all the pages are compiled. before the test starts, use OptimizeIt to garbage collect. Once that is done, I start the test and look at the number of threads and size of the heap. If there's a memory leak, either the thread count will increase, or the heap will grow rapidly. Once I see either one, I then switch to the call graph to get a better picture of which methods are getting called. Usually, that is enough to point towards a culprit. repeat, and rinse as many times as needed until you've squashed all bugs and leaks. peter lin Matt Woodings [EMAIL PROTECTED] wrote: I just read your post this morning (I am lurking today as I have a few issues of my own to clear up :-) ) and I think that is some really good advice you gave. I do have a question though. Once you have noticed you have a memory leak, how do you go about locating it? Matt - Do you Yahoo!? Yahoo! Tax Center - File online by April 15th
RE: Tomcat performance issue?
This evening I did the same with JProbe under 360 requests as you describe and this led to me gaining a 38% speedup. The main bottleneck I found was some very simple tags I have were calling out.flush() at the end. Thiw was consuming 14 seconds of time to flush 1 string from the tag. The tag is called many times within our JSPs because it calls the current skin label. By simply removing the flush call the tag call method time across the load test went down to 2s. Not bad hey. There were other areas which I solved with application scope caching and a bean pool for a 3rd party bean that takes ages to initialise a connection. I am getting there slowly but surely but Yoav I think was right all along and it is the code and you have to profile it and examine those call graphs!!! ADC -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Mon 12/04/2004 19:53 To: Tomcat Users List Cc: Subject: Re: Tomcat performance issue? luckily I have a license of Borland OptimizeIt. What I do is I start tomcat using OptimizeIt. Then I create a test plan in JMeter. Once tomcat is running, I warm it up by sending it a couple hundred requests to make sure all the pages are compiled. before the test starts, use OptimizeIt to garbage collect. Once that is done, I start the test and look at the number of threads and size of the heap. If there's a memory leak, either the thread count will increase, or the heap will grow rapidly. Once I see either one, I then switch to the call graph to get a better picture of which methods are getting called. Usually, that is enough to point towards a culprit. repeat, and rinse as many times as needed until you've squashed all bugs and leaks. peter lin Matt Woodings [EMAIL PROTECTED] wrote: I just read your post this morning (I am lurking today as I have a few issues of my own to clear up :-) ) and I think that is some really good advice you gave. I do have a question though. Once you have noticed you have a memory leak, how do you go about locating it? Matt - Do you Yahoo!? Yahoo! Tax Center - File online by April 15th FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE --- QAS Ltd. Developers of QuickAddress Software a href=http://www.qas.com;www.qas.com/a Registered in England: No 2582055 Registered in Australia: No 082 851 474 --- /FONT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat performance issue?
glad the suggestion helps. I firmly believe in profiling code to make sure simple little mistakes that appear harmless aren't killing performance. I'm constantly amazed at how little things improve performance. the benefit of using OptimizeIt or any other good profiling tool is well worth it. that's my biased perspective :) peter lin --- Allistair Crossley [EMAIL PROTECTED] wrote: This evening I did the same with JProbe under 360 requests as you describe and this led to me gaining a 38% speedup. The main bottleneck I found was some very simple tags I have were calling out.flush() at the end. Thiw was consuming 14 seconds of time to flush 1 string from the tag. The tag is called many times within our JSPs because it calls the current skin label. By simply removing the flush call the tag call method time across the load test went down to 2s. Not bad hey. There were other areas which I solved with application scope caching and a bean pool for a 3rd party bean that takes ages to initialise a connection. I am getting there slowly but surely but Yoav I think was right all along and it is the code and you have to profile it and examine those call graphs!!! ADC -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Mon 12/04/2004 19:53 To: Tomcat Users List Cc: Subject: Re: Tomcat performance issue? luckily I have a license of Borland OptimizeIt. What I do is I start tomcat using OptimizeIt. Then I create a test plan in JMeter. Once tomcat is running, I warm it up by sending it a couple hundred requests to make sure all the pages are compiled. before the test starts, use OptimizeIt to garbage collect. Once that is done, I start the test and look at the number of threads and size of the heap. If there's a memory leak, either the thread count will increase, or the heap will grow rapidly. Once I see either one, I then switch to the call graph to get a better picture of which methods are getting called. Usually, that is enough to point towards a culprit. repeat, and rinse as many times as needed until you've squashed all bugs and leaks. peter lin Matt Woodings [EMAIL PROTECTED] wrote: I just read your post this morning (I am lurking today as I have a few issues of my own to clear up :-) ) and I think that is some really good advice you gave. I do have a question though. Once you have noticed you have a memory leak, how do you go about locating it? Matt - Do you Yahoo!? Yahoo! Tax Center - File online by April 15th FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE --- QAS Ltd. Developers of QuickAddress Software a href=http://www.qas.com;www.qas.com/a Registered in England: No 2582055 Registered in Australia: No 082 851 474 --- /FONT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance issue?
Denise Mangano wrote, On 4/9/2004 10:05 PM: I've tried searching the archives but have come up empty-handed. A few days ago I received a few complaints that my users hit a certain point in the application and could go no further. This point was when Apache gives control to Tomcat. I checked the log and found this. Apr 4, 2004 2:19:43 PM org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: All threads (75) are currently busy, waiting. Increase maxThreads (75) or check the servlet status The only thing that did the trick was restarting Tomcat and Apache. Any ideas on what these errors mean? Like the messages say, all Tomcat threads are busy and you've hit the maximum number of threads which can be processed concurrently. Sounds like you've got either a bug in a servlet causing it to not return, or your server is simply overloaded. You can get a stack trace from the JVM to help debug this issue pretty easily. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance issue?
David Rees [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Denise Mangano wrote, On 4/9/2004 10:05 PM: I've tried searching the archives but have come up empty-handed. A few days ago I received a few complaints that my users hit a certain point in the application and could go no further. This point was when Apache gives control to Tomcat. I checked the log and found this. Apr 4, 2004 2:19:43 PM org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: All threads (75) are currently busy, waiting. Increase maxThreads (75) or check the servlet status The only thing that did the trick was restarting Tomcat and Apache. Any ideas on what these errors mean? Like the messages say, all Tomcat threads are busy and you've hit the maximum number of threads which can be processed concurrently. Sounds like you've got either a bug in a servlet causing it to not return, or your server is simply overloaded. You can get a stack trace from the JVM to help debug this issue pretty easily. Also, when running behind Apache, you have need to have at least as many Tomcat threads as you have Apache children allowed (since each child will be talking to a single thread). You should probably increase the maxThreads on you AJP/1.3 Connector to match what you've configured for MaxChildren in Apache. If you expect your loads to come in bursts, then you can configure maxSpareThreads low to allow Tomcat to discard threads that are freed up by Apache killing off children. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Autoreply: Re: Tomcat performance issue?
Hello, Due to the increased volume of SPAM this mailbox has been closed. Please contact us via http://www.directxtras.com/ContactUS.asp We apology for the inconvenience. Best Regards, -- The DirectXtras Team - DirectXtras - Xtra Power for Director and Authorware - http://www.directxtras.com Sites with something to say - http://www.SpeaksForItself.com - Your message reads: Received: from mail.apache.org (unverified [208.185.179.12]) by mail2.intermedia.net (Rockliffe SMTPRA 4.5.6) with SMTP id [EMAIL PROTECTED] for [EMAIL PROTECTED]; Sat, 10 Apr 2004 12:45:24 -0700 Received: (qmail 61062 invoked by uid 500); 10 Apr 2004 19:45:04 - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Post: mailto:[EMAIL PROTECTED] List-Id: Tomcat Users List tomcat-user.jakarta.apache.org Reply-To: Tomcat Users List [EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] Received: (qmail 61040 invoked from network); 10 Apr 2004 19:45:03 - Received: from unknown (HELO main.gmane.org) (80.91.224.249) by daedalus.apache.org with SMTP; 10 Apr 2004 19:45:03 - Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BCOPc-0001fg-00 for [EMAIL PROTECTED]; Sat, 10 Apr 2004 21:45:08 +0200 Received: from lsanca1-ar19-4-46-072-212.lsanca1.dsl-verizon.net ([4.46.72.212]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for [EMAIL PROTECTED]; Sat, 10 Apr 2004 21:45:08 +0200 Received: from wbarker by lsanca1-ar19-4-46-072-212.lsanca1.dsl-verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for [EMAIL PROTECTED]; Sat, 10 Apr 2004 21:45:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: [EMAIL PROTECTED] From: Bill Barker [EMAIL PROTECTED] Subject: Re: Tomcat performance issue? Date: Sat, 10 Apr 2004 12:58:23 -0700 Lines: 35 Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] X-Complaints-To: [EMAIL PROTECTED] X-Gmane-NNTP-Posting-Host: lsanca1-ar19-4-46-072-212.lsanca1.dsl-verizon.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: news [EMAIL PROTECTED] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N David Rees [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Denise Mangano wrote, On 4/9/2004 10:05 PM: I've tried searching the archives but have come up empty-handed. A few days ago I received a few complaints that my users hit a certain point in the application and could go no further. This point was when Apache gives control to Tomcat. I checked the log and found this. Apr 4, 2004 2:19:43 PM org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: All threads (75) are currently busy, waiting. Increase maxThreads (75) or check the servlet status The only thing that did the trick was restarting Tomcat and Apache. Any ideas on what these errors mean? Like the messages say, all Tomcat threads are busy and you've hit the maximum number of threads which can be processed concurrently. Sounds like you've got either a bug in a servlet causing it to not return, or your server is simply overloaded. You can get a stack trace from the JVM to help debug this issue pretty easily. Also, when running behind Apache, you have need to have at least as many Tomcat threads as you have Apache children allowed (since each child will be talking to a single thread). You should probably increase the maxThreads on you AJP/1.3 Connector to match what you've configured for MaxChildren in Apache. If you expect your loads to come in bursts, then you can configure maxSpareThreads low to allow Tomcat to discard threads that are freed up by Apache killing off children. -Dave - 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]
