Hi Chris, Thanks for your reply.
> > On 5/13/2009 5:28 PM, Pantvaidya, Vishwajit wrote: > > My setup is tomcat 5.5.17 + mod_jk 1.2.15 + httpd 2.2.2. I am using > > AJP1.3. > > Ooooold versions of everything. Consider upgrading? > [Pantvaidya, Vishwajit] Yes, sure - we will upgrade at some point of time. But since upgrading all our servers will be some work, that may not happen right away. > > Every 2-3 days with no major load, tomcat throws the error: "SEVERE: > > All threads (200) are currently busy, waiting..." > > > > I have been monitoring my tomcat TP-Processor thread behavior over > > extended time intervals and observe that: - even when there is no > > activity on the server, several TP-Processor threads are in RUNNABLE > > state while few are in WAITING state > > It appears that you have 200 threads available. How many (on average) > are RUNNABLE versus WAITING? (The two counts should add to 200, unless > there's some other state (BLOCKED?) that the threads can be in, but you > didn't mention any other states). [Pantvaidya, Vishwajit] Here are figures from 3 of the servers which have not yet run out of threads (so the thread count does not add up to 200). I have taken these late at night when no users are present, so I was expecting all threads to be Waiting for tomcat thread-pool. 1. Total TP-Processor threads 48, Waiting 46, Runnable 2 2. Total TP-Processor threads 40, Waiting 29, Runnable 11 3. Total TP-Processor threads 120, Waiting 7, Runnable 113 > > > - RUNNABLE threads stack trace shows "java.lang.Thread.State: > > RUNNABLE at java.net.SocketInputStream.socketRead0(Native > > Method)..." > > This indicates that the client has not yet disconnected, and is probably > still sending data. If there were not any data waiting, the state should > be BLOCKED. > > > - WAITING thread stack trace shows "java.lang.Thread.State: WAITING > > on > > org.apache.tomcat.util.threads.threadpool$controlrunna...@53533c55" > > These are idle threads. > > > - tomcat adds 4 new TP-Processor threads when a request comes in and > > it can find no WAITING threads > > Wow, 4 new threads? That seems like 3 too many... [Pantvaidya, Vishwajit] Do you think this could be because of the application? I was under the impression that there is some tomcat config parameter that controls this - which was set to 4. > > > So I conclude that my tomcat is running out of threads due to many > > threads being in RUNNABLE state when actually they should be in > > WAITING state. Is that happening because of the socket_keepalive in > > my workers.properties shown below? > > worker.socket_keepalive just keeps the connection between Apache httpd > and Tomcat "alive" in case you have an overzealous firewall that closes > inactive connections. The request processor shouldn't be affected by > this setting. > > > Why are threads added in bunches of 4 - is there any way to configure > > this? > > > > My workers config is: > > > > Worker...type=ajp13 Worker...cachesize=10 > > Are you using the prefork MPM? If so, cachesize should be /1/. > [Pantvaidya, Vishwajit] Could you please elaborate. What is the prefork MPM? > > Worker...cache_timeout=600 Worker...socket_keepalive=1 > > Worker...recycle_timeout=300 > > Are these timeouts necessary? Why not simply let the connections stay > alive all the time? > [Pantvaidya, Vishwajit] Sure we could. But for any production change, I would have to offer a good enough reason. > > Earlier posts related to this issue on the list seem to recommend > > tweaking: - several timeouts - JkOptions +DisableReuse > > This will require that every incoming HTTP connection opens up a new > ajp13 connection to Tomcat. Your performance will totally suck if you > enable this. But if it's the only way for you to get your application > working properly, then I guess you'll have to do it. I suspect you /will > not/ have to enable +DisableReuse. > [Pantvaidya, Vishwajit] I was seeing earlier posts on this list mention some disagreement on the performance impact of setting +DisableReuse. Otherwise I would not even think of this. By the way, the above 3 figures I provided are without connectiontimeout being set for Connector element in server.xml. - Vish. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
