On 22.01.2017 07:37, smith wrote:
Hi, Chris
We don't just care about free, we care about active too. We know how many free
also means how many are active
We are using HTTP
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?
Max threads : 200
-----------------
That is the maximum number of threads that tomcat will ever allocate, no matter how busy
your server becomes.
Current thread count : 23
-------------------------
That is how many threads have been allocated and exist so far. If you do not use an
Executor, then this number will never go down again (but it may go up). Included in this
count are :
a) the threads currently busy processing a request
b) the threads which may not be actually executing a request, but are blocked on a
keep-alive connection, waiting if there is another request coming on that same client
connection. These threads are not available for a new client connection, but they are
available to process a new request on the same client connection for which they have
already processed at least one request recently.
c) the threads which are not doing anything, and which are available to process new
connections and new requests on such new connections
Current thread busy: 1
----------------------
This the thread (a) above. It is in fact the thread which is processing your "manager"
request.
Keeped alive sockets count: 1
-----------------------------
This a thread in status (b) above. It is not the same thread as (a).
It is not available for a new client connection, because it is still waiting on its
current client connection. But it is available for a new request *on the same connection*,
for the remainder of its keep-alive timeout.
If there is no no new request on that same connection, then when the keep-alive timeout
expires, it will close the connection and go to status (c).
If there is a new request on the same connection, it will go to status (a) and process
that request; and when it is finished, the timeout will be reset to the keep-alive timeout
and it will return to status (b).
So you have :
total threads : 23
- busy threads : -1
- keepalive threads : -1
====================
= available for new connections : 21
From time to time, tomcat will look at how many threads are in status (c) above. It if
it not at least minSpareThreads, additional threads will be created until there are
minSpareThreads in status (c), with a maximum of maxThreads threads in total.
If you server was receiving now suddenly 50 new requests from 50 new clients at the same
time, then :
- 21 requests would be processed by the 21 threads currently in status (c) (which will go
to status (a)
- tomcat would create 29 new threads immediately, to process the other 29 requests. These
threads would start in status (a), and when their request is finished, they would go to
status (b) for the keepAlive timeout
- possibly, the background watchdog would run at that same moment and see that there are
no longer minSpareThreads available in status (c). It would then create new threads in
status (c), to bring this back to minSpareThreads.
At the end of this, you would now have (possibly) 60 threads in total, forever, which will
slowly go back all to status (c) if no more requests are coming.
If you want another behaviour, then you should use an Executor.
-Smith
-----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
-----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
---------------------------------------------------------------------
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
