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.