[jboss-as7-dev] Limiting Server Thread Usage

[Scott Stark]

The question of whether this is the right limit is one I have raised, 
especially since the limit is being imposed via a pam_limits module 
which actually limits the number of processes a user is allowed. A java 
thread is mapping to a process in this model, which further blurs the 
effectiveness/validity.

However, this is an issue that does commonly come up with system admins 
as a way of gauging max requests and therefore some measure of the max 
resource requirements.

Perhaps a global limit is really not an effective approach.

Similar to how we have a global view of ports in use, perhaps just 
having a global view of the thread pools in the domain model stats would 
be enough. If I can see of the server thread pools with the min/max 
settings, and there is a base thread pool dsl for min/max settings in 
every subsystem utilizing a thread pool, one can at least understand the 
thread usage, and make some choices about how to limit it.

On 9/14/11 10:53 AM, Jason T. Greene wrote:
> Moving to a new thread.
>
> The big problem we run into with this is that almost every application
> of a thread pool that we have needs to be highly tailored to its usage
> to get the most optimal performance. So we end up with quite a few
> different pools and it becomes difficult to impose a server wide limit.
>
> There however some potential strategies we could take. Although I am
> unsure as to how the overall effectiveness would be:
>
> 1. Sharing idle threads between pools
> 2. Force everything to go through a special blocking thread factory via
> instrumentation of java.lang.Thread. Any attempt to allocate over the
> max would lead to thread reclamation attempts and finally blocking until
> a timeout is reached.
> 3. Some kind of auto-tuning weighting model. If the max total threads is
> N, force all thread pools to use a percentage of N, potentially based on
> establishing current config value divided by combined total.
>
> One thing I wonder though is if cloud providers are "barking up the
> wrong tree"? It seems a better limitation of an application is raw CPU
> clock time and max memory usage. How they split that time into threads
> doesn't really affect the scalability of the physical server, it's all
> virtual process performance (who cares if someone wastes time context
> switching?).
>
> On 9/14/11 10:39 AM, Scott Stark wrote:
>   >  The other big cross cutting concern is controlling the total number of
>   >  threads in use by the application server. When running under a
>   >  constrained environment that uses something like pam_limits module to
>   >  control how many process(==java threads) a user can have, it is
>   >  difficult to know what the server max thread usage is right now.
>   >
>