走自己的路

路漫漫其修远兮,吾将上下而求索

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  50 随笔 :: 4 文章 :: 118 评论 :: 0 Trackbacks

 星期一早上到了公司,据称产品环境抛出了最可爱的异常—OutOfMemory, 它是这样来描述他自己的:

java.lang.OutOfMemoryError: unable to create new native thread

而且这位仁兄竟然还堂而皇之地同时出现在了3application里面,所有应用全部遭殃。

那可爱的OOM是如何产生的呢?直接原因是创建的线程太多了,根本原因是某个地方的内存限制了。

搜罗了一下在网上找到了一个计算公式:

(MaxProcessMemory - JVMMemory – ReservedOsMemory) / (ThreadStackSize) = Number of threads 

MaxProcessMemory:进程最大的寻址空间,但我想这个值应该也不会超过虚拟内存和物理内存的总和吧。关于不同系统的进程可寻址的最大空间,可参考下面表格:

Maximum Address Space Per Process

Operating System

Maximum Address Space Per Process

Redhat Linux 32 bit

2 GB

Redhat Linux 64 bit

3 GB

Windows 98/2000/NT/Me/XP

2 GB

Solaris x86 (32 bit)

4 GB

Solaris 32 bit

4 GB

Solaris 64 bit

Terabytes

JVMMemory: Heap + PermGen

ReservedOSMemoryNative heapJNI

便可推导出单个JVM Instance可支持的最大线程数的估计值:

(MaxProcessMemory<固定值> – Xms<初始化值,最小值> – XX:PermSize<初始化值,最小值> – 100m<估算值>) / Xss = Number of threads<最大值>

在本地(32bit windows)试了试,可达的线程的最大值差不多就是这个数,它不受物理内存的限制,会利用虚拟内存,从任务管理器看到memory已经是5500 m左右了(开了两个jvm),我机器的物理内存是2g,也不知道这个准不准,后来还抛出了“unable to create new native thread”的兄弟“Exception in thread "CompilerThread0" java.lang.OutOfMemoryError: requested 471336 bytes for Chunk::new. Out of swap space?“。

本地测完了后,就该轮到dev环境了,linux2.664bit,双核,8G(虚拟机),总的物理内存是16g。在上面整了一下,创建到了15000多个线程的时候挂掉了。此时其他application也不能创建新的线程,而且db也报错了,操作系统不能fork新的线程了。这应该是操作系统的哪里限制了新线程的创建,

·         max threadlinux2.6似乎是32000

·         最大可用内存:物理内存+虚拟内存

·         配置,在linux可以限制可用资源的大小,show一下这些参数

core file size          (blocks, -c) 0

data seg size           (kbytes, -d) unlimited

file size               (blocks, -f) unlimited

pending signals                 (-i) 1024

max locked memory       (kbytes, -l) 32

max memory size         (kbytes, -m) unlimited

open files                      (-n) 65536

pipe size            (512 bytes, -p) 8

POSIX message queues     (bytes, -q) 819200

stack size              (kbytes, -s) 10240

cpu time               (seconds, -t) unlimited

max user processes              (-u) 16384

virtual memory          (kbytes, -v) unlimited

file locks                      (-x) unlimited

为了进一步确定在linux上一个jvm因为达到了最大寻址空间OOM了,不会影响其他jvm,我在Linux做了进一步测试,一开始用Sun文档中说的最大寻址空间3G试了一下,发现根本不对,达到了3G后还是非常high地在创建新的线程。于是出动超级无敌变态的JVM初始化配置。

oracle   27408 27017 12 13:45 ?        00:00:07 /home/oracle/ias1013/FWAPP/FWDev/jdk/bin/java -server -Xmx4096m -Xms4096m -XX:+HeapDumpOnOutOfMemoryError -XX:PermSize=4096m -XX:MaxPermSize=4096m -XX:HeapDumpPath=/home/oracle/ias1013/FWAPP/FWDev/j2ee/OC4J_OOMTest/workEnv/log -Xss100m

结果在create 3379个线程后,“unable to create new native thread”出现了,这时其他jvm都是可以create新线程的。如果按照上面公式计算,linux 64bit2.6kernel,它的最大寻址空间肯定超过了300g,当然应该还没有达到可用内存的限制,因为其他JVM还create新线程。

我还怀疑是不是oracle application server上的某个配置参数限制了总的线程数,影响了所有application,但我们的产品环境一个application就是一个单独的application server。

现在基本上可以确定是操作系统哪里设置错了,我想System team的帅哥们应该把产品环境的某个参数配置错了,系统本身的影响肯定不会有了,因为产品环境上我们只create800左右个线程,就OOM了,那应该就是配置的问题了,怀疑的参数有下面四个

max user processes              (-u) 2048

virtual memory          (kbytes, -v) unlimited

max memory size         (kbytes, -m) unlimited

stack size              (kbytes, -s) 10240

最后发现只有max user processes virtual memory对总的线程数有影响,我把max user processes降到2048后,发现此时只能创建 2000左右个线程了(Xms64m, Xss1m),进一步地把virtual memory下调到2048000K发现能创建的就更少了1679Xms64m, Xss1m),而它只会对当前shell起作用,而多个application server应该是不同的shell,所以他是打酱油的。另外两个参数好像就是来做做俯卧撑的,操作系统stack size是不应该会有什么影响,我们把它上调到102400,还是可以创建2000左右的线程数(max user processes),因为java有自己的线程模型,它的栈的大小是用Xss来控制的。Max memory size不知道是啥东东,照理说如果是最大内存应该不会只在旁边做俯卧撑,那这个参数到底是春哥还是曾哥,查了一下man ulimit,有下面解释

              -a     All current limits are reported

              -c     The maximum size of core files created

              -d     The maximum size of a process data segment

              -f     The maximum size of files created by the shell

              -l     The maximum size that may be locked into memory

              -m     The maximum resident set size (has no effect on Linux)

              -n     The maximum number of open file descriptors (most systems do not allow this value to be set)

              -p     The pipe size in 512-byte blocks (this may not be set)

              -s     The maximum stack size

              -t     The maximum amount of cpu time in seconds

              -u     The maximum number of processes available to a single user

              -v     The maximum amount of virtual memory available to the shell

Has no effect on Linux”就足以证明它确实只是来做做俯卧撑的。最后查出只有“max user processes”会对所有application能创建总的线程数有限制。



posted on 2009-09-25 10:55 叱咤红人 阅读(34235) 评论(10)  编辑  收藏 所属分类: J2SE and JVM

评论

# re: 剥下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣[未登录] 2010-01-19 17:16 菜鸟
我最近总也是碰见OOM(Exception in thread "CompilerThread0" java.lang.OutOfMemoryError: requested 1056888 bytes for Chunk::new. Out of swap space?)
不知道大侠能否指点下偶?

1、服务器硬件配置如下:
Type IBM X3850
Processor Details 2132 MHz * 16
Memory 16G
操作系统是RedHat企业版5.0,64位服务器

2、我使用的JDK是jdk-1_5_0_12-linux-i586,应用服务器是Weblogic 9.2,weblogic服务器setDomain.sh文件的参数配置如下:
# PATCH_LIBPATH=[myPatchLibpath] (unix)
# PATCH_PATH=[myPatchPath] (unix)

. ${WL_HOME}/common/bin/commEnv.sh

WLS_HOME="${WL_HOME}/server"
export WLS_HOME

WLI_HOME="${WL_HOME}/integration"
export WLI_HOME

MEM_ARGS="-Xms3072m -Xmx3072m"
export MEM_ARGS

if [ "${JAVA_VENDOR}" = "Sun" ] ; then
if [ "${PRODUCTION_MODE}" = "" ] ; then
MEM_DEV_ARGS="-XX:CompileThreshold=8000 -XX:PermSize=96m -XX:+UseParallelGC "
export MEM_DEV_ARGS
fi
fi

# Had to have a separate test here BECAUSE of immediate variable expansion on windows

if [ "${JAVA_VENDOR}" = "Sun" ] ; then
MEM_ARGS="${MEM_ARGS} ${MEM_DEV_ARGS} -XX:MaxPermSize=256m"
export MEM_ARGS
fi

  回复  更多评论
  

# re: 剥下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣[未登录] 2010-01-19 17:17 菜鸟
我的邮箱是ooxoo024@hotmail.com,请大侠指点下,先谢谢了。  回复  更多评论
  

# re: 剥下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣 2010-01-20 07:42 叱咤红人
帅哥,
1.用ulimit看一下,虚拟内存是否做了限制。这个异常我测试下来是出现在当总内存(物理内存+虚拟内存)不够的情况下。
2.用profile工具或者gc log看一下内存的使用情况。看程序中是否有内存溢出的风险。
3.出问题时系统中的线程使用情况。kill -3 或者用TDA.  回复  更多评论
  

# re: 剥下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣 2010-03-22 18:51 zhaixf
帅哥,我也做了下相应的测试,发现公式中的:
便可推导出单个JVM Instance可支持的最大线程数的估计值:
(MaxProcessMemory<固定值> – Xms<初始化值,最小值> – XX:PermSize<初始化值,最小值> – 100m<估算值>) / Xss = Number of threads<最大值>
Xms不会影响创建线程的个数,起作用的应该是:-Xmx
其他地方和我想的基本一致,但是我在测试过程中遇到了比较奇怪的问题,没有办法解释:下面是我测试的情况,重点关注“-Xmx1692m”,似乎作为了一个分隔线,之上的也能用公式解释,之下的也能用公式解释。

-Xms3060m -Xmx3060m
-Xss2048k (thread :94)

-Xms2560m -Xmx2560m
-Xss2048k (thread :157)

-Xms2048m -Xmx2048m
-Xss2048k (thread :221)
-Xss1024k (thread :598)

-Xms1792m -Xmx1792m
-Xss1024k (thread :683)

-Xms1692m -Xmx1692m
-Xss1024k (thread :49)(进程自己结束)

-Xms1560m -Xmx1560m
-Xss2048k (thread :31)(进程自己结束hs_err_pid24865.log)

-Xms1536m -Xmx1536m
-Xss2048k (thread :34)(进程自己结束hs_err_pid24865.log)
-Xss1024k(thread :100)

-Xms1024m -Xmx2048m
-Xss2048k (thread :221)

-Xms1048m -Xmx1048m
-Xss2048k (thread :95)

-Xms560m -Xmx1152m
-Xss2048k(thread :82)
-Xss1024k(thread :228)

-Xms1048m -Xmx3560m
-Xss2048k (thread :32)(进程自己结束)  回复  更多评论
  

# re: 剥下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣 2010-03-22 22:02 ldd600
@zhaixf
1. 和Xss值有关,你的结果也可以说明这一点,或者您可将Xss设置的变态一点
2. 您用的是32位还是64位系统,您的虚拟内存是多大,虚拟内存还受其他程序的影响。
  回复  更多评论
  

# re: 剥下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣 2010-11-17 11:57 higkoo
不错,顶起!  回复  更多评论
  

# re: 剥下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣 2013-02-25 14:52 excite
数据记录的很详细,很有参考价值!  回复  更多评论
  

# re: 剥下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣 2013-04-02 15:17 wxylion1
good job  回复  更多评论
  

# re: 剥下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣[未登录] 2013-05-15 17:09 Ryan
很好,呵呵有价值的文章。  回复  更多评论
  

# re: 剥下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣[未登录] 2015-12-09 15:37 呵呵
除了公式外,还和max user processes 限定有关吧?  回复  更多评论
  


只有注册用户登录后才能发表评论。


网站导航: