-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vishwajit,
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? > 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). > - 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... > 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/. > 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? > 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. > I am planning to do the following to resolve our problem: - upgrade > jk to latest version - e.g. 1.2.28 Upgrading is (almost) always a good idea. > - replace recycle_timeout with connection_pool_timeout - add > connectionTimeout in server.xml - add JkOptions +DisableReuse I think these settings will only reduce performance. If you want my advice, I'd simplify your configuration as much as possible, then add settings as you need them. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkoNf5EACgkQ9CaO5/Lv0PCswQCfQ101OnbCFnTEOu0e8wqlVt1Q gycAn1hohlsIrYyEEno0jGrGglE2yInF =hWV8 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
