[jboss-as7-dev] Limiting Server Thread Usage

Stuart Douglas stuart.w.douglas at gmail.com
Fri Sep 16 02:35:50 EDT 2011


What about if we had 1 underlying thread pool that provides all the threads, and then subsystems use a custom executor that provides a 'view' of this underlying thread pool. 

So for instance we have the main thread pool that has a max of 25 threads, we could then give the EJB remote invocation pool is then given an executor that can use a maximum of 10 threads from the pool.

This would also allow you to give these executors a priority, so for example you could give the web subsystem thread pool a higher priority to make sure that web requests always get handled first.

I'm not really sure how well this would work, but I just thought I would put it out there.

Stuart

On 15/09/2011, at 3: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.
>> 
> 
> -- 
> Jason T. Greene
> JBoss AS Lead / EAP Platform Architect
> JBoss, a division of Red Hat
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev




More information about the jboss-as7-dev mailing list