Java JVM Maximum number of threads setting

Recently, you want to test the maximum concurrent number under OpenFire, you need to open a large number of threads to simulate the client. There are a number of questions about how many threads can open in a JVM instance, so it's time to actually test, simply Google, and find the following factors that affect the amount of threads:

-xms	intial java Heap Size
-xmx	Maximum Java heap Size
-xss	The stack size for each thread
System Limitations	Maximum number of threads available for the system

The test procedures are as follows: Java code   import java.util.concurrent.atomic.atomicinteger;      public  class testthread extends thread {       private static  final atomicinteger count = new atomicinteger ();           public static void main (String[] args)  {            while  (true)                  (New testthread ()). Start ();           }           @Override        public void  run ()  {           system.out.println ( Count.incrementandget ());              while  ( True)  &nbsP             try {                    thread.sleep (Integer.MAX_ VALUE);               } catch  ( Interruptedexception e)  {                    break;                }       }  }  
test Environment:System: Ubuntu 10.04 Linux Kernel 2.6 (32-bit)

Memory: 2G

jdk:1.7

Test Results:

Ø System limitations are not considered

-xms	-xmx	-xss	Results
1024m	1024m	1024k	1737
1024m	1024m	64k	26077
512m	512m	64k	31842
256m	256m	64k	31842

No threads can be created on the system when the number of threads created has reached 31,842.

As can be seen from the test results above, increasing heap memory (-XMS,-XMX) reduces the number of threads that can be created, and increasing the thread stack memory (minimum 60K of this parameter value in a-xss,32 bit system) also reduces the number of threads that can be created.

Ø combined with system limitations

The limit of the number of threads 31842 is determined by the maximum number of threads that the system can generate:/proc/sys/kernel/threads-max, but its default value is 32080. Modify its value to 10000:echo 10000 >/proc/sys/kernel/threads-max, the modified test results are as follows:

-xms	-xmx	-xss	Results
256m	256m	64k	9761

In this case, it means that you can configure as many threads as possible. To make changes:echo 1000000 >/proc/sys/kernel/threads-max, the modified test results are as follows:

-xms	-xmx	-xss	Results
256m	256m	64k	32279
128m	128m	64k	32279

The number of threads found is no longer growing after reaching 32279. Check it out, 32-bit Linux system can create the maximum number of PID is 32678, this value can be modified by /proc/sys/kernel/pid_max (modified method with Threads-max), But in the 32 system this value can only be changed to small, can not be larger. In the case of Threads-max, the corresponding test results of the modified Pid_max are as follows:

Pid_max	-xms	-xmx	-xss	Results
1000	128m	128m	64k	582
10000	128m	128m	64k	9507

The situation on Windows should be similar, but may be less than the number of threads that can be created on linux,windows. The threading model based server is always limited by the number of threads.

Summary:

The maximum number of heap memory that can be generated by the JVM, the stack memory size of thread, the maximum number of threads that the system can create (the Java thread implementation is based on the thread mechanism of the underlying system, Windows _beginthreadex, Linux under Pthread_create) affects three aspects. The amount can be estimated based on the maximum memory (2G on 32-bit system), heap memory, thread stack memory that the Java process can access.

Preface:

Testing under 64-bit Linux systems (CentOS 6, 3G memory), there is also a parameter that limits the number of threads: the max User process (viewable by ulimit–a, default value 1024, Ulimit–u can be modified by this value), This value is not unlimited in the 32-bit Ubuntu test environment above.

Will Threads-max,pid_max,max userprocess, these three parameter values are modified to 100000,-xms,-xmx as small as possible (128m,64m),-XSS as small as possible (64-bit minimum 104k, preferably 128k). Prediction in such a test environment, the number of threads will only be limited by the test environment memory size (3G), but the actual test result is the number of threads in the reach of 32K (32768, the number of creation is about 33000) when the JVM is thrown warning: attempt to Allocate stack guard pages failed, then appears OutOfMemoryError cannot create a local thread. After looking at the memory, I found that there is a lot of idle, so it should not be memory capacity. Google this warning has no effect, for the time being for some reason, pending further study.

Order 2:

Today accidentally found the article [7], immediately tried, and sure enough this factor will affect the number of thread creation, according to the article described the number of/proc/sys/vm/max_map_count doubled, from 65536 to 131072, the total number of threads created to reach 65000 +, Computer Basic to Die (3G memory) ... The function of this parameter is briefly checked, and the description in [8] is as follows:

"This file contains themaximum number of memory map areas a process may have. Memory map Areas areused as a side-effect of calling malloc, directly by Mmap and Mprotect, when AndAlso shared Li Braries.

While most applications needless than a thousand maps, certain programs, particularly, malloc debuggers, mayconsume lots of them, e.g., up to one or two maps per allocation.

Thedefault value is 65536. "

OK, the problem is finally resolved, and concludes with a summary of the factors that affect the number of Java threads:

Java Virtual machine itself:-XMS,-XMX,-XSS;

System Limitations:

/proc/sys/kernel/pid_max,

/proc/sys/kernel/thread-max,

max_user_process (ulimit-u),

/proc/sys/vm/max_map_count.