Re: [jboss-as7-dev] Limiting Server Thread Usage

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. > > > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev