tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier (tomcat) ...@ice-sa.com>
Subject Re: FW: tomcat 8080 thread not reduced
Date Fri, 20 Jan 2017 08:59:23 GMT
On 20.01.2017 03:59, smith wrote:
> Hi, chris:
>
>> "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. How many are in keepAlivedStatus
>

That may be my fault, in my contributions earlier.
I believe that it is reasonable to assume that "busy" also counts the threads which are 
currently "in keepAlive" status. That is because these threads are not "free" to handle 
new requests yet from other clients than the one which "owns" the connection on which they

are in keepAlive.
But I do not know the code, so someone else may want to confirm/correct this.

Anyway, you do have a simple way to verify this : reduce the keepAlive to 5 seconds, 
instead of 20, and see how it impacts the counts that you are seeing.
If keepAlive counts as "busy", then you should see less "busy" threads on average.
If keepAlive does not count as busy, then you will see no difference.

One more proviso : the above is for the case where clients connect to tomcat directly, 
without a front-end, which may itself create a pool of permanent connections to tomcat.
(Chris already mentioned that).
If there is such a front-end, and it does something like "pings" on each connection to the

tomcat back-end connections all the time, then you would have, on the tomcat side, an 
alsmost constant number of threads in keepAlive wait status.

All in all, considering your ultimate purpose (to determine when your tomcat is getting 
close to the limit of what it can handle, and decide if you need more tomcats or not), I 
believe that your current focus on the number of tomcat threads active or not, may not be

the best diagnostic tool.

Maybe a better tool would be to look at the number of connections which are waiting to be

accepted. This should always be 0, or small.  If it starts growing, then that is a clear 
signal that tomcat is getting saturated. (This is related to the "acceptCount" attribute 
of the Connectors).

Another tool may be to look at how long it takes tomcat to respond to requests (or at 
least some specific types of requests).  You can probably set a baseline, when you know 
that tomcat is really not heavily loaded (maybe on your development system e.g.).  And 
then, when you see this response time increasing seriously, is when you should start 
analysing why. (*)

This kind of approach would have the advantage of focusing on what really matters in the 
end : the ability of your server (as a whole : hardware, OS, tomcat and applications 
included) to handle a given number of requests within a given time interval, with /your/ 
mix of clients and applications.


(*) because the reason may be for example that you need more memory, not more threads.

>
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Thursday, January 19, 2017 4:38 PM
> To: Tomcat Users List
> Subject: Re: FW: tomcat 8080 thread not reduced
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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:chris@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:chris@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:chris@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>>> --------------------------------------------------------------------
> - -
>>
>>>>
>>>>
>>>>
>>
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>> ---------------------------------------------------------------------
>>
>>>
>>>
>>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>> ---------------------------------------------------------------------
>>
>>>
>>>
>>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>>
>>
>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>>
>>
>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYgOtqAAoJEBzwKT+lPKRYzssP/RYY4eIAw8DS39+2z3uk7zva
> OChcof7S6yclKCQ4KjpVq9lsSPndOjOt4MaWtMyktKEoKIjvn25f/KSDJLIUy7HX
> T5t/8NAix/BbkNlBeQjGDN5rrx3QUWuudb4E1ERydafWDt1cBfb+ry2jdLxa7x7g
> TbQkP+tFl4C59lJ3P+vkqr2qZiUT8VSR5ljXxK1i6EWrT7oN3D0xCai5fEV7rgUZ
> ah3Xj5QXztu+Tw/8e0rkFn/8KnUv+zLVvc/wTgr+nd9hKuYXMk11nOQfnIsLS5vO
> VmxJJBmLb0UFFWw50ST8248caJjRsOnMbUeJqcc+71PJ6aeZ2hoxZXVXyLJuNENH
> LIlUTRjSwa7Ij02InUJ/xj8uQg0cm4ayBWDbfOz2ki23GtD5UgUKBDLTxDp2JqaZ
> uUwzkHSTv4P9x+NDK4/oYDJ38if6/XF4kClm2LqLoGccb4pENdnP4QMQxUTNLnjg
> OJwLEkbjinvfRe79ADoOlGIyKRMVg/qlSoPgSRnqqbHPXehBNlV7IQn+s3F/kK0A
> gzMT30lZ0al3aANUy2852Bn+xmG9DhBkOTBio+bQiCBdMSE+J7BQ3YOjKLT7GcX5
> Jg0i3LloP29PI5c5fmDn08Mr/kmJVf6KartGHp9W6QRfKeJVdVWzrHl3owKtl3y0
> VCaH5idITnyUntc7akwi
> =dWIg
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message