[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