-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Smith,
On 1/22/17 1:37 AM, smith wrote: > We don't just care about free, we care about active too. We know > how many free also means how many are active If you are using a dynamically-sized pool, then you don't really know how many you have free if you sample active, or how many you have active if you sample free ones. You have to collect both stats in order to know whether or not there is a problem. Of course, the size of the pool can chance between samples of free/active so you are never getting a perfect picture. > We are using HTTP That wasn't clear from any of your previous posts. In that case keepalive could be an issue. The solution is to use a NIO connector. > Let's me take one example from manager status: (this is the > manager output) Max threads: 200 Current thread count: 23 Current > thread busy: 1 Keeped alive sockets count: 1 > > Current thread count: 23 I want to know if these 23 threads are > free to use, or they are active, cannot accept new connection? Here > are Keeped alive sockets count, it's only 1, is this 1 for the > busy thread or a thread in 23? The current thread count tells you how many java.lang.Thread objects are being managed by the thread pool. It says nothing about their state. The 200 is obviously the limit of threads that *would* be managed by the pool. I would have to read the code to find out if a keep-alive connection counts as "busy" or not. But you don't want keepAlive connections to hold-up a thread, so you should use an NIO connector. Since you are using Tomcat 8 (albeit an old version) without specifying a certain type of connector, you are already getting either the NIO connector or the APR connector (if the native library is available). Neither of those connectors will hold-up a thread for a keepalive connection. I suspect that "busy:1, keepalive:1" for you means that there is currently 1 thread actually processing a request, and you have 22 threads idle. The keepalive:1 means that one socket connection is in the keepalive state, but it's not consuming a thread. - -chris > -----Original Message----- From: Christopher Schultz > [mailto:ch...@christopherschultz.net] Sent: Friday, January 20, > 2017 10:29 PM To: Tomcat Users List Subject: Re: FW: tomcat 8080 > thread not reduced > > 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 > > > --------------------------------------------------------------------- > > > 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/ iQIcBAEBCAAGBQJYhiVJAAoJEBzwKT+lPKRYLXMP/iVhfgmu6TkURPoYpbzJirOb km4WRQFtGazUtLEM0hPS8KGc3sa62YJJEyflbvi0PL/lX0BK1FE6h8Pb300Ik+pY Jfdc5QeAtChjjEDGiKIRz+YBwRidNqy4GGlq7gPzsNMDSc1GTl6vCnR//p3E9ey1 c8a6A1oYUeVtFho21CwDG8dtUwL5ycNgBKqLuPgfBckNeK6ldmX2KR1Ctjnck1yQ 5obgagWaB89FyDarAIIdjQEOSai2o0Ui/c7GbzjBTu5SkEgG9gT9U9RlC0H/J4vD zXtlKYR0QKSAZ5pnh3LFDYQdkNJ7MAIbAYXxFVofFi+bG1gOXQ8ex3/3kzJDrDl6 e9kKKI4Yn/h1Qh7pvrXEzlXSJh6fhr4rG1uGqQdSNIq+29a3MKxpIWDUG4ybdqOZ JaqRS7Hif2ARFTn8eh+NoOTZocIVdoFq9qv4jc/RT8O/uz89DfYvZqQmsXwHwEgo HrLDDiykwMo+2zI5Zo9Okyka/vMabBpUk560QZ9Raej6PaFJHXMg2L2tQiSk27hH 01to3eYLqCgYNFP4XCIJ1kec/XzhbbkkvE87N+chSOMeFDEH2lKonT7nZds8XLA+ 79gWfLDIhTagZOmzH5Y+Bd/tWu7iWJyFRzWOf6v6YZMdPHvD5egIBBbu0E3XUJBB veJFv1GTsAVxma5V4lrP =Zmkp -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
