John, On Fri, Apr 28, 2017 at 11:48 AM, Rainer Jung <rainer.j...@kippdata.de> wrote: > Am 27.04.2017 um 22:21 schrieb Mark Thomas: >> >> On 27/04/17 20:08, John Cartwright - NOAA Federal wrote: >>> >>> Thanks for your reply Mark! My sysadmin tells me just that we're >>> using "the defaults" for event_mpm. However we are still using the >>> BIO AJP connector: >>> >>> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" >>> maxThreads="300" minSpareThreads="25" >>> maxSpareThreads="75" connectionTimeout="20000"/> >>> >>> Is there a way I can tell from the Tomcat side when there is thread >>> starvation? >> >> >> You'd need to look at the number of active connections. If it gets to >> 300 then you likely have a problem. >> >> netstat might be the least invasive way of doing that. Other options >> include the Manager app, JMX and thread dumps. >> >> Switching to NIO will allow you to server more connections with the same >> number of threads. > > > I assume you are using the latest mod_jk version? > > The current version of mod_jk also counts the total connection number (sum > of connections from all Apache child processes to your Tomcat) and makes it > available via the status worker for monitoring. The counting was a bit buggy > in older versions, but should be correct in the latest one. > > Event MPM and mod_jk: the relevant phase in Apache is the handler phase, > where the actual request forwarding is done by mod_jk. Things do not really > need to change in the handler phase for proxying modules with event MPM. > mod_jk does not need to know about the MPM or behave specific, the > forwarding runs synchronously. By default mod_jk uses as many connections > per Apache process as you have worker threads per Apache process configured. > On the Tomcat side with BIO you need as many threads for the AJP connector > as all you Apache fronting that Tomcat might have threads in total. Using > the NIO connector on the Tomcat side is indeed better than BIO especially > when you expect lots of concurrency (many Apache threads configured). Make > sure you also use a recent Tomcat patch level then. > > What messages did you get in your mod_jk error log?
I also have the same question. Please check mod_jk log entries in the time frame when you are getting 503s. It must have some clues. We had similar type of problem a year ago(although we were using mod_proxy_http). Later we found that backend Tomcat servers were not responding to httpd's ping. As a result httpd was throwing 503s sporadically. In our case long GC pauses were causing the problem. We tuned GC and problem went away completely. You can check if you are having something like that or not. Again you need to correlate 503 occurrences with GC logs. https://tomcat.apache.org/connectors-doc/reference/workers.html > > For the mod_jk config, a good starter is the config files we bundle with the > source download of mod_jk. You can also find them under > > http://svn.apache.org/viewvc/tomcat/jk/trunk/conf/ > > These files set timeouts etc. > > Regards, > > Rainer > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
