Linux下JVM中可变通的最大Thread数量

2019-10-23 23:24 来源:未知

近来想测量试验下Openfire下的最大并发数,要求开大气线程来效仿客商端。对于贰个JVM实例到底能开多少个线程向来心存疑忌,所以筹算实际测量检验下,简单google了把,找到影响线程数量的因素有下边多少个:

-Xms

intial java heap size

-Xmx

maximum java heap size

-Xss

the stack size for each thread

系统限制

系统最大可开线程数

测量试验程序如下:

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)             try {                 Thread.sleep(Integer.MAX_VALUE);             } catch (InterruptedException e) {                 break;             }     } } 

测量检验情状:

系统:Ubuntu 10.04 Linux Kernel 2.6 (32位)

内存:2G

JDK:1.7

测量试验结果:

◆ 不考虑系统节制

-Xms

-Xmx

-Xss

结果

1024m

1024m

1024k

1737

1024m

1024m

64k

26077

512m

512m

64k

31842

256m

256m

64k

31842

在开立的线程数量达到318肆十个时,系统中不可能创设任何线程。

由地方的测验结果能够看见增大堆内部存款和储蓄器(-Xms,-Xmx)会减削可成立的线程数量,增大线程栈内部存款和储蓄器(-Xss,三12个人系统中此参数值最小为60K)也会回降可创设的线程数量。

◆ 结合体系限定

线程数量31842的限量是是由系统能够扭转的最大线程数量调控的:/proc/sys/kernel/threads-max,可其暗中同意值是32080。改过其值为10000:echo 10000 > /proc/sys/kernel/threads-max,修正后的测量试验结果如下:

-Xms

-Xmx

-Xss

结果

256m

256m

64k

9761

这样的话,是还是不是意味着可以配备尽量多的线程?再做修正:echo 1000000 > /proc/sys/kernel/threads-max,改善后的测量试验结果如下:

-Xms

-Xmx

-Xss

结果

256m

256m

64k

32279

128m

128m

64k

32279

开掘线程数量在到达32279过后,不再进步。查了一下,叁10位Linux系统可制造的最大pid数是32678,这一个数值能够经过/proc/sys/kernel/pid_max来做改革(校订章程同threads-max),不过在32系统下这一个值只可以改小,不恐怕更加大。在threads-max一定的意况下,改进pid_max对应的测量检验结果如下:

pid_max

-Xms

-Xmx

-Xss

结果

1000

128m

128m

64k

582

10000

128m

128m

64k

9507

在Windows上的场地应该左近,可是相比Linux,Windows上可创制的线程数量大概越来越少。基于线程模型的服务器总要受限于那些线程数量的限定。

总结:

JVM中可以转移的最大额由JVM的堆内部存款和储蓄器大小、Thread的Stack内部存储器大小、系统最大可创制的线程数量(Java线程的达成是依照底层系统的线程机制来落到实处的,Windows下_beginthreadex,Linux下pthread_create)几个方面影响。具体多少得以依靠Java进程能够访谈的最大内存(叁十二位系统上相仿2G)、堆内部存款和储蓄器、Thread的Stack内部存款和储蓄器来忖度。

序:

在64位Linux系统(CentOS 6, 3G内存)下测量试验,发掘还应该有叁个参数是会约束线程数量:max user process(可通过ulimit –a查看,暗中认可值1024,通过ulimit –u能够更正此值),那一个值在上面的31位Ubuntu测量试验处境下并无界定。

将threads-max,pid_max,max user process,这八个参数值都改革成100000,-Xms,-Xmx尽量小(128m,64m),-Xss尽量小(60个人下纤维104k,可取值128k)。事先预测在这里样的测量检验景况下,线程数量就只会受限于测验碰到的内部存款和储蓄器大小(3G),可是实际上的测量试验结果是线程数量在高达32K(32768,创设的数码最多的时候大致是33000左右)左右时JVM是抛出警告:Attempt to allocate stack guard pages failed,然后现身OutOfMemoryError无法创制本地线程。查看内部存款和储蓄器后发掘还应该有那多少个悠闲,所以应当不是内部存款和储蓄器体积的原故。Google此警报无果,一时半刻不知什么原因,有待进一步切磋。

序2:几天前无意中发觉小说[7],立即试了下,果然这些因素会影响线程创制数量,按文中描述把/proc/sys/vm/max_map_count的数目翻倍,从65536改为131072,创立的线程总量量达到65000+,计算机基本要卡死(3G内部存款和储蓄器)… 轻易查了下那个参数的职能,在[8]中的描述如下:

“This file contains the maximum number of memory map areas a process may have. Memory map areas are used as a side-effect of calling malloc, directly by mmap and mprotect, and also when loading shared libraries.

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

The default value is 65536.”

OK,这一个难点到底完满化解,最终计算下影响Java线程数量的因素:

Java虚构机本身:-Xms,-Xmx,-Xss;

系统节制:

/proc/sys/kernel/pid_max,

/proc/sys/kernel/thread-max,

max_user_process(ulimit -u),

/proc/sys/vm/max_map_count。

图片 1

TAG标签:
版权声明:本文由990888藏宝阁发布于关于计算机,转载请注明出处:Linux下JVM中可变通的最大Thread数量