So what you are suggesting is my mod_jk and tomcat parameters in server.xml are messed up ..
Here is my current setup I have one apache load balancing to 2 tomcat workers Maxclients = 512 ThreadsPerChild = 256 Connection_pool_size = 256 Tomcat MaxThreads = 150 I will suggest my team to change this to ... connection_pool_size = 120 - which means that I will have 120*2(2 apache server procs) = 240 threads per tomcat Tomcat maxthreads = 300 So out of total 512 worker threads , a max of 480 threads will be used by mod_jk leaving the rest for serving static content. is my math correct? Thanks! ________________________________ From: Martin Gainty <mgai...@hotmail.com> To: Tomcat Users List <users@tomcat.apache.org> Sent: Monday, May 18, 2009 11:23:58 AM Subject: RE: Tomcat not closing threads some documentation: http://httpd.apache.org/docs/2.0/mod/mpm_common.html MaxClients: The MaxClients directive sets the limit on the number of simultaneous requests that will be served. Any connection attempts over the MaxClients limit will normally be queued, up to a number based on the ListenBacklog directive. Once a child process is freed at the end of a different request, the connection will then be serviced. For non-threaded servers (i.e., prefork), MaxClients translates into the maximum number of child processes that will be launched to serve requests. The default value is 256; to increase it, you must also raise ServerLimit. For threaded and hybrid servers (e.g. beos or worker) MaxClients restricts the total number of threads that will be available to serve clients. The default value for beos is 50. For hybrid MPMs (your situation) the default value is 16 (ServerLimit) multiplied by the value of ThreadsPerChild. Therefore, to increase MaxClients to a value that requires more than 16 processes, you must also raise ServerLimit. ThreadsPerChild This directive sets the number of threads created by each child process. The child creates these threads at startup and never creates more. If using an MPM like mpm_winnt, where there is only one child process, this number should be high enough to handle the entire load of the server. If using an MPM like worker, where there are multiple child processes, the total number of threads should be high enough to handle the common load on the server. The default value for ThreadsPerChild is 64 when used with mpm_winnt The default value is 25 when used with other configurations such as worker also from mladens discussion of connection_pool_size calcs based on Apache HTTPD Prefork vs Worker http://www.mail-archive.com/users@tomcat.apache.org/msg14767.html Apache Prefork configuration Apache 1.3 and Apache 2.x-prefork create a separate child process for each client connection, meaning that if you have default 250 MaxClients, you can end up with MaxClients * connection_pool_size connections to the Tomcat, that would in your case be 250000. (and in the case of ThreadsPerChild parameter MaxClients*64*connection_pool_size) Apache Worker configuration With worker mpm the connection_pool_size defaults to ThreadsPerChild, that in the final gives the MaxClients connections to the Tomcat. So the default value for connection_pool_size is always ThreadsPerChild that with prefork mpm is by design always 1. (in the case of ThreadsPerChild parameter not being null MaxClients*ThreadsPerChild) HTH Martin ______________________________________________ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Mon, 18 May 2009 07:43:04 -0700 From: chetan_chh...@yahoo.com Subject: Re: Tomcat not closing threads To: users@tomcat.apache.org Our network team is already engaged and looking into this. We had several instances of tomcats locking up today. I have attached one such thread dump here .. Can some of you pls take a look and point me into the right direction? From: rad muthu <rmuth...@gmail.com> To: Tomcat Users List <users@tomcat.apache.org> Sent: Wednesday, May 13, 2009 8:05:08 PM Subject: Re: Tomcat not closing threads Chetan, We had similar issue with Sun solaris and weblogic. My system admin found out there is a socket read errors are going on . He used snoop command in solaris. After tuning the TCP parameters the issue got resolved. You might also need to something like that. Thanks Krish On Wed, May 13, 2009 at 11:57 AM, Chetan Chheda <chetan_chh...@yahoo.com>wrote: > I guess I need to ask my question again. Im primarily an HP-UX > administrator and recently inherited this web based application ... > > We are having some issues in accomodating additional user > load/functionality. While a part of the team is looking at optimizing code, > I am responsible for infrastructure componants. > > One particular focus area for me is the mod_jk and tomcat configurations. > 1. Last of April saw one of the tomcat's stop processing requests. Looking > at the mod_jk.log I saw the following errors > Unable to get the free endpoint for worker XXX from 37 slots .... > I have setup the status servlet for mod_jk in which I saw that max slots > were opened. Thinking that mod_jk needs more number of connections, I > basically set it to ThreadsPerChild from worker MPM > > 2. Now we are randomly seeing that even a simple activity as user login > causes a spike in used tomcat connector threads. Eventually all tomcat > threads are used and no new requests can be serviced. > > So, long story short, is my apache, mod_jk and tomcat configuration in > sync? > Maxclients = 512 > ThreadsPerChild = 256 > So that means 2 server processes with 256 threads each. > > I have 2 worker threads in my worker.properties file with > connection_pool_size=256. > Does this mean that total number of connections into tomcat = 256 * > 2(number of workers) * 2(number of server procs) = 1024 ?? > > Do I need to change the connection_pool_size to 120 . Which means 120*2 *2 > = 480 and that leaves the remainder of apache threads for static content? > > 3. I have worker.XXX.cache_timeout=900 and no connectionTimeout in > server.xml . Is this why connections remain open? > > Thanks, > Chetan > > > ________________________________ > From: "Caldarale, Charles R" <chuck.caldar...@unisys.com> > To: Tomcat Users List <users@tomcat.apache.org> > Sent: Tuesday, May 12, 2009 10:47:00 PM > Subject: RE: Tomcat not closing threads > > > From: Chetan Chheda [mailto:chetan_chh...@yahoo.com] > > Subject: Re: Tomcat not closing threads > > > > I managed to get a thread dump during one such tomcat hangs. Most of > > the threads are in the following status ... > > The ones you show are simply waiting for input from httpd; that's a pretty > normal state. When looking at a thread dump, it's often the oddball thread > that's not doing what the rest are that is causing a problem. However, if > all of the threads are just waiting to receive something from httpd, then > you may have to look outside of Tomcat for the cause. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > _________________________________________________________________ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_BR_life_in_synch_052009
