繁体   English   中英

Tomcat关闭时内存不足

[英]Out of Memory on Tomcat Shutdown

我的问题的简短描述:我使用部署的Wicket应用程序启动Tomcat。 当我想关闭tomcat时,我收到以下错误消息:

Error occurred during initialization of VM
 java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:640)
at java.lang.ref.Reference.<clinit>(Reference.java:145)

我正在运行以下设置:

  • Ubuntu Linux:10.04(清晰),内核为2.6.18-028stab094.3
  • Java版本:“1.6.0_26”Java HotSpot(TM)64位服务器VM
  • Tomcat版本:7.0.23
  • jvm_args:-Xms512m -Xmx512m -XX:MaxPermSize = 205m(这些是通过CATALINA_OPTS添加的,没有别的)
  • Wicket 1.5.1
  • Tomcat在具有ModProxy的子域上配置了两个虚拟主机
  • 我的应用程序在appbase目录中部署为ROOT.war(如果我部署一个或两个应用程序,它没有任何区别)
  • '''没有部署的应用程序不会导致OOM关闭''',除非我搞乱了jvm args
  • 战争的大小约为500k,所有库都部署在tomcat / common / lib(我在conf / catalina.properties中添加到common.loader的目录)
  • ulimit -u - >无限制

当我检查Tomcat管理器应用程序时,它会说明以下有关JVM内存的信息:

Free memory: 470.70 MB Total memory: 490.68 MB Max memory: 490.68 MB
(http connector) Max threads: 200 Current thread count: 6 Current thread busy: 1

'top'或'free -m'类似:

Mem:   2097152k total,  1326772k used,   770380k free,        0k buffers
20029 myuser   18   0  805m 240m  11m S    0 11.7   0:19.24 java  

我试图启动jmap来获取堆的转储,它也因OutOfMemoryError而失败。 实际上只要部署了我的一个或两个应用程序,任何其他java进程都会因相同的OOM错误而失败(参见顶部)。

部署应用程序时会出现此问题。 所以有些事情是严重错误的。 然而,该应用程序实际上运行了很长一段时间。 但我也在应用程序中看到了OOM,所以我不相信平静。

我的应用程序是使用自定义筛选器类? 可能是吗?

为了完整性(希望如此),这是我的common / lib中的库列表:

activation-1.1.jar
antlr-2.7.6.jar
antlr-runtime-3.3.jar
asm-3.1.jar
asm-commons-3.1.jar
asm-tree-3.1.jar
c3p0-0.9.1.1.jar
commons-collections-3.1.jar
commons-email-1.2.jar
dependencies-provided.tgz
dom4j-1.6.1.jar
ejb3-persistence-1.0.2.GA.jar
geronimo-annotation_1.0_spec-1.1.1.jar
geronimo-jaspic_1.0_spec-1.0.jar
geronimo-jta_1.1_spec-1.1.1.jar
hibernate-annotations-3.4.0.GA.jar
hibernate-commons-annotations-3.1.0.GA.jar
hibernate-core-3.3.0.SP1.jar
hibernate-entitymanager-3.4.0.GA.jar
hibernate-search-3.1.0.GA.jar
javassist-3.4.GA.jar
joda-time-1.6.2.jar
jta-1.1.jar
log4j-1.2.16.jar
lombok-0.9.3.jar
lucene-core-2.4.0.jar
mail-1.4.1.jar
mysql-connector-java-5.1.14.jar
persistence-api-1.0.jar
quartz-2.1.1.jar
servlet-api-2.5.jar
slf4j-api-1.6.1.jar
slf4j-log4j12-1.6.1.jar
stringtemplate-4.0.2.jar
wicket-auth-roles-1.5.1.jar
wicket-core-1.5.1.jar
wicket-datetime-1.5.1.jar
wicket-extensions-1.5.1.jar
wicket-request-1.5.1.jar
wicket-util-1.5.1.jar
xml-apis-1.0.b2.jar

我感谢任何暗示或甚至推测给我额外的想法尝试。

更新 :我进行了更多测试,发现仅在部署我的一个或两个应用程序时才会出现此行为。 在“空”tomcat上没有发生这种行为(这是我犯了jvm args的错误)

Update2 :我正在尝试尝试在虚拟框中重现此行为,我想用分析器调试它。 我仍然不相信在2GB RAM上运行我的设置是不可能的。

Update3 (10/01/12):我正在尝试运行jenkins而不是我自己的应用程序。 相同的行为,所以它肯定是服务器配置问题。 调用maven时Jenkins作业失败,所以我甚至不需要尝试下面建议的关闭hack,因为我在运行Jenkins时需要第二个java进程。 有人向我建议,因为这是一个虚拟服务器ulimits可能是从外部强加的,我将无法看到它们。 我想我会就此问一个新问题。 大家好。

Update4 (02/05/12):请参阅下面的包含提示的答案。 我将在这里澄清一些:我现在95%确定错误发生,因为我达到了我的线程限制。 但是因为这是一个虚拟服务器,下面描述的方法无法检查这个值,因为ulimit看不到它,这让我感到困惑,直到今天我才发现这是我看到的“numproc”值。在Parallels Power Panel中,我可以登录我的虚拟服务器。 numproc有资源警报,但直到现在我才看到它们。 该值的硬限制为96,当然我无法改变。 numproc的当前值对应于在切换“H”以查看线程后我用“top”看到的进程数。 我很难找到这个,因为这个numproc值隐藏在面板深处。 可悲的是,如果你想用apache和mysql运行一个tomcat,96是一个相当低的数字。 我也很伤心,我甚至无法在我的托管合同的小字体中找到这个价值,而且我敢说我的应用程序非常相关。 所以我想我需要升级服务器。

谢谢大家的帮助,最后每个人都帮助我找出问题所在。

似乎你打开了太多线程。

使用此命令:

ulimit -u

结果是什么 ? 应该是这样的:

max user processes (-u) 100

如果这是正确的,您可以编辑此文件:

/etc/security/limits.conf

以及以下修改:

#<domain> <type> <item> <value>
user soft nproc 10000
user hard nproc 10000

tomcat关闭过程包括通过tcp端口向正在运行的tomcat VM发送命令/字。 此端口在server.xml中配置(如果我记得正确的话,现在就在我的手机上写入)。 到现在为止还挺好。

不幸的是,关闭脚本通过使用与tomcat相同的java选项启动2. VM来实现此目的。 你的系统根本没有足够的内存。

作为一个解决方案,您可以使用telnet或其他东西编写自己的停止脚本。

如果需要,我可以稍后帮忙。

希望有所帮助。 VielegrüsseBert

你可以这样生存一段时间。 您需要做的就是在需要重新启动时终止tomcat进程。 这不是一个好方法,但主要关注的是您的应用程序正确运行。

在我看来,从长远来看,您可能需要订购一个可用RAM更多的主机方案。

上周,我遇到了与tomcat安装类似的问题。 我设法通过给tomcat一个较小的堆来修复它。 像这样的东西:

export CATALINA_OPTS=”-Xms256m -Xmx512m”

在开始Tomcat之前可能有帮助。 在此期间你将不得不以老式的方式杀死它,使用kill -9 ;)

编辑:你也可以看看这里 ,看来tomcat会自动创建一堆“备用”线程,但你可以限制这些以及配置中的最大线程数。 希望能帮助到你。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM