Does anybody have any idea about the maximum no. of threads that a jvm can create in winnt / solaris. Also, what is the optimum number and what is the maximum number?
In weblogic 5.1 the maximum no. of threads for the server is based on the no. of processors. Why should weblogic place such a restriction like if you have 4 processors, you can set the maxthreads property in weblogic.properties file to 60.
I have seen in discussions where people say that thread creation can be controlled by -ms and -mx heap options during jvm startup.
As weblogic is suggesting 15 threads per processor, does sun suggest the no. of threads per processor?. the weblogic's suggestion of 15 threads per processor doesn't look to me as an optimum one. Assume that i have one processor, and i have 128 mb ram, if weblogic's optimum thread no. of 15 is considered for 128 mb ram, then what happens if i have 256 mb ram. Shouldn't the no. of threads created be greater ?
Doesn't the thread creation depend on the available memory ? or what else ?
your comments are welcome ..
Who told you all of this?!?
I've worked at BEA for three years and have been on over 2 dozen clustering assignments.
So, here is what you need to know: Clustering is an inexact science. The number of threads that you specify per VM depends upon all of these factors:
-Speed of the processors
-# of processors
-Amount of RAM
-The type of threading model that you are using (native threads, non-native threads, OS threads)
-The type of requests that your threads are handling. For instance, if you are using WLS to handle batch processing, these requests are very timely and processor intensive. You will need to make sure that you have a pool of threads to handle the low-priority, long running batch requests and a pool of threads to handle the high-priority, short-duration web page requests (as an example).
Now, some things to keep in mind:
1) BEA charges licenses of WLS based upon the number of CPUs that your VM is using.
2) As a result of this, the analysis that you do shouldn't be merely dependent upon the number of threads in a VM, but the appropriate # processes / # of threads per process mix.
Most of my experiences deal with systems where the type of request is the web request, db lookup / update, collate information, return content. I would say that 90% of the requests made to WLS systems follow this pattern.
Through the experiences that I've seen and from other architects that I've worked with, a typical WLS VM will be operating on a machine with a configuration like this:
1) 2-8 CPUs
2) Typically a Sun SparcStation, HP server, or Linux box.
3) 1/2 GIG - 2 GIG of RAM.
In scenarios like this, where you can use native threads (threads are supported by the OS and you can map VM threads to the OS), I've seen the ability for a single VM to effectively handle 30-45 threads. I typically see some sort of minimal diminishing returns up to around 70 threads where significant diminishing returns come into play. Some discussions I've had with other architects claim that they are running 75-100 threads per VM without any performance bottlenecks.
So, estimating the number of threads per VM is an inexact science. I always start out with 40 and then run many, many tests altering the thread count before I settle on an optimal point.
Also, you need to keep in mind that WLS has two type of threads: those that are handling incoming requests (placing the requests on the job queue) and those threads taking requests off of the job queue and executing them. If you use only 15 threads in a VM instance, you will have by default 5 threads reading web requests and 10 threads doing the work. You may need to alter this ratio slightly if your system has a very low client request level.
Thanks Tyler. I found the weblogic's suggestion of 15 threads per processor from "Execute Threads" section under
As you said, speed of the processors is also another factor, do you have any idea about the typical processor speed used in production environments ?
No, not really... Typically, it's very, very fast.
thanks a lot for your comprehensive overview. Maybe you can also shed some some light to another aspect. A different bea doc gives estimates for setting execute thread count in relation to database connections being served (i.e. number of connections in pool plus more to handle non-database sockets), in which case the number of execute threads can be way higher. The fundamental question I have is what is the starting point for calculating the parameter. CPU number? Number of concurrent processes? Database connections?
As a example, a one cpu machine has 100-150 database connections. By cpu the execute thread cound should be 15 to, say ,40-50. By database connections it should be over 150.