-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Smith,
On 1/19/17 9:59 PM, smith wrote: >> "busy" is the same as "active". > > When not use <Executor>, our busy thread always keep under 10 > while the currentThreadCount keeps high (these are get from tomcat > manager), So we really don't know how many threads are truly free. Why do you care how many are free? Isn't it more important to know how many are active? For example, I run my app servers with maxThreads="150" for the most part. Then, I have Nagios notify me if the "active count" goes above 135 (that's 90% of my maxThreads). Nagios, like many monitoring systems, won't scream the first time it sees something. Instead, it will check again a few times before complaining. That means that as long as I don't see any significant duration where the active thread count exceeds 135, I don't get any alarms going off. And I don't care how many "free" threads I have. I've decided that I want "150 and NO MORE". Nothing else matters except the active count. I don't happen to allow the thread pool to re-size downward (fewer threads), but if I did, I wouldn't have to change my monitoring at all. What? The active count is 10 and the total pool size is 20? I don't care. Wake me up when the active thread count stays high for a while, indicating to me that we are getting hammered. > How many are in keepAlivedStatus Use NIO and forget about it. Besides, you are using *AJP*. Every thread is *always* in a keepalive state. So keepalive == idle as far as Tomcat is concerned. If you were using HTTP, then keepalive would be an issue (and NIO would be the answer), but you aren't, so it's not. - -chris > -----Original Message----- From: Christopher Schultz > [mailto:ch...@christopherschultz.net] Sent: Thursday, January 19, > 2017 4:38 PM To: Tomcat Users List Subject: Re: FW: tomcat 8080 > thread not reduced > > Smith, > > On 1/18/17 8:25 PM, smith wrote: >> I don't care if the threads will be reduced, I just want to know >> why. > > Okay. > >> And we want to use the account to determine when the tomcat >> capacity is not enough that we need to add max configuration or >> add new tomcat servers. > > Set your initial and max threads to the same value (pool size = > constant) and then monitor the "active count" with a Nagios warning > at e.g. 80% usage. > >> Since not use the <Executor>, the busy thread account also cannot >> tell us the correct active threads count. > > "busy" is the same as "active". > >> In another email thread, you said if use <Executor>, it will tell >> us the right active thread count not just busy count, right? > > I would always use an <Executor> for at least two different > reasons: > > 1. Thread management (e.g. reducing threads if necessary) 2. Shared > thread-pools (no need to have port 8080 and 8443 with separate > pools) > > -chris > >> -----Original Message----- From: Christopher Schultz >> [mailto:ch...@christopherschultz.net] Sent: Wednesday, January >> 18, 2017 3:28 PM To: Tomcat Users List Subject: Re: FW: tomcat >> 8080 thread not reduced > >> Smith, > >> On 1/18/17 12:47 AM, smith wrote: >>> So the tomcat default executor will not reduce the thread count >>> until it reach to the max configuration? > >> By default, you get a thread pool that isn't as smart as an >> executor. > >>> Will it reduce when it reach to max? > >> Not unless you use an <Executor>. > >>> And why the default not reduce the thread? > >> Because it didn't do so in the past, before <Executor> was >> introduced. > >> I'm curious: if you are willing to have e.g. 200 threads >> available at any time during the life of the JVM, why does it >> matter if those threads are reduced during times of inactivity? > >> I think of threads as a resource like memory, where if you are >> going to allocate X resources, you may as well allocate X >> resources and be done with it. Growing and shrinking pools of >> things just adds complexity and reduces performance. > >> Idle threads are "free" other than using a little bit of memory. >> So why is it so important for those threads to stop when they >> don't have any work for a while? > >> -chris > >>> -----Original Message----- From: Christopher Schultz >>> [mailto:ch...@christopherschultz.net] Sent: Tuesday, January >>> 17, 2017 7:18 PM To: Tomcat Users List Subject: Re: FW: tomcat >>> 8080 thread not reduced > >>> Smith, > >>> On 1/16/17 8:22 PM, smith wrote: >>>> Yes, I think thread count should be reduced when those >>>> threads are idle > >>>> Is this right? Or it will not reduced? > >>> Id you want Tomcat to reduce the number of idle threads, you'll >>> need to explicitly configure an <Executor> and use that with >>> your <Connector> . > >>> -chris > >>>> -----Original Message----- From: Christopher Schultz >>>> [mailto:ch...@christopherschultz.net] Sent: Monday, January >>>> 16, 2017 2:20 PM To: Tomcat Users List Subject: Re: FW: >>>> tomcat 8080 thread not reduced > >>>> Smith, > >>>> There are your only active <Connector>s: > >>>> On 1/14/17 1:30 AM, smith wrote: >>>>> <Connector port="8080" protocol="HTTP/1.1" maxThreads="300" >>>>> connectionTimeout="20000" redirectPort="8443" /> > >>>>> [snip] > >>>>> <Connector port="8009" protocol="AJP/1.3" >>>>> redirectPort="8443" /> > >>>> You have not changed any settings from the default. What >>>> makes you think that your thread count should be reduced when >>>> those threads are idle? > >>>> -chris > >>>> ------------------------------------------------------------------- - - > >>>> - - > >>>> >>>> >>>> > >>> 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 > > >>> -------------------------------------------------------------------- - - > >>> >>> >>> > >> 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 > > >> --------------------------------------------------------------------- > >> > > > 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 > > > --------------------------------------------------------------------- > > 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 > -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYgo82AAoJEBzwKT+lPKRYcMYQAJYCFBKsDAfUlcTOagqMQARA JEQudRYLRUt4LDGiKiCz9q3bZImxuH63jFj5biRMi88jBa3uCF/mQciodbxVrldL yAVchYCSFay0kwj8YLCLJ8zsuVziQKob2/X06QERzumpCVUOXoUM9cswYA0om3LS LNGamV4xeb5l60uoiBYlxg7K+7ivbwDpN67+hu8hCEdxSyYal8s3XRihxHPAGdS4 LIw0cxigWmg+zW+DKs8k4t6PqdVOahSrIlgZ8pxSKjqoji/wP3zKQSHExDMJYJMf GxRzsdHRKRozmIo9oRxRnieRESV7laNwndgmNb2/LriVgHE2wTFf1ylMsl7ho9kz Zz13tuCPt822dIqfoKnx1Re+tms0nyUzg7ihto53ZgD0GrdxeJFzOG4wFKQJdvLW hoGoBifK48FW8Q0ryudmDPQH0slvw0QAH3pG5qJOu9+UZ4/GuCFECv3pwVOCdhH6 kgj3H32ZsakC6A9JkOwvVb/4Tyg+UzhjaEY6UZP1hPmDxpwICyXjqgqUWuB3WI5L QxF6ofi/B4+DpmE4uh6I3LohIW+2Q4/5l/3D9t4CqysLHyJVenYd04tL6dSwCNOd upuZ9FDJqg0bamKfE5c9Pjvka7J00GmHkgCcSLYdS8NMwrb80dHcsH3CwWU/fHyO Jq6xTAUf5k8iAowhYnkh =YRYR -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
