热门标签 | HotTags
当前位置:  开发笔记 > 运维 > 正文

一次tomcat自动关闭的bug解决

这篇文章主要给大家介绍了一次关于tomcat自动关闭的bug的解决过程,文中通过示例代码介绍的非常详细,对大家学习或者使用tomcat具有一定的参考学习价值,需要的朋友们下面来一起学习学习吧

前言

最近一个运行了4年的javaee web项目,经常接到客户反馈系统无法打开。登录服务器查看服务,发现是tomcat自动关闭了。基本是3到4天发生一次。

运维人员开始以为是其他服务杀死了tomcat服务,没放在心上,解决方法就是直接重启tomcat。

最终捅了篓子,运维人员被客户投诉,扣了一个月的绩效。

解决这个bug兜兜转转来到了我这里。既然接到任务,那就开干,没有解决不了的bug。

系统的运行环境如下:

  • tomcat6.0
  • 32位jdk7.0
  • window server2003 32位,32G内存。

查看日志,如果tomcat闪崩,都会在tomcat的bin目录下生成以"hs_err"开头的日志文件。打开最新的日志文件,首先看到的是下面一段话:

# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 32756 bytes for ChunkPool::allocate
# Possible reasons:
# The system is out of physical RAM or swap space
# In 32 bit mode, the process size limit was hit
# Possible solutions:
# Reduce memory load on the system
# Increase physical memory or swap space
# Check if swap backing store is full
# Use 64 bit Java on a 64 bit OS
# Decrease Java heap size (-Xmx/-Xms)
# Decrease number of Java threads
# Decrease Java thread stack sizes (-Xss)
# Set larger code cache with -XX:ReservedCodeCacheSize=
# This output file may be truncated or incomplete.
#
# Out of Memory Error (allocation.cpp:211), pid=7864, tid=6556
#
# JRE version: Java(TM) SE Runtime Environment (7.0_79-b15) (build 1.7.0_79-b15)
# Java VM: Java HotSpot(TM) Server VM (24.79-b02 mixed mode windows-x86 )
# Failed to write core dump. 

大概意思就是内存不够了,无法分配32756字节的空间。同时给出几个解决方法:

1、减少系统内存负载;

2、增加物理内存或者交换空间;

3、在64位操作系统上使用64位jdk;

4、减少java heap大小;

5、减少java线程数量;

6、减少java线程堆栈大小。

通过上面的内容可以得出,jvm无法分配32756 bytes的内存空间。

从接到任务开始,我一直以为是jvm配置出错,导致内存不够用,只需调整下新生代、老年代的配置即可。

继续往下看日志文件,找到"GC Heap History (10 events):"这一行,这个记录jvm最后10次垃圾回收时堆的变化情况。

GC Heap History (10 events):
Event: 572312.299 GC heap before
{Heap before GC invocatiOns=5046 (full 357):
PSYoungGen total 201472K, used 200685K [0x573c0000, 0x63bc0000, 0x63bc0000)
eden space 198144K, 100% used [0x573c0000,0x63540000,0x63540000)
from space 3328K, 76% used [0x63540000,0x637bb528,0x63880000)
to space 3328K, 0% used [0x63880000,0x63880000,0x63bc0000)
ParOldGen total 843776K, used 422602K [0x23bc0000, 0x573c0000, 0x573c0000)
object space 843776K, 50% used [0x23bc0000,0x3d872b18,0x573c0000)
PSPermGen total 262144K, used 51848K [0x03bc0000, 0x13bc0000, 0x23bc0000)
object space 262144K, 19% used [0x03bc0000,0x06e62138,0x13bc0000)
Event: 572312.305 GC heap after
Heap after GC invocatiOns=5046 (full 357):
PSYoungGen total 201472K, used 1103K [0x573c0000, 0x63bc0000, 0x63bc0000)
eden space 198144K, 0% used [0x573c0000,0x573c0000,0x63540000)
from space 3328K, 33% used [0x63880000,0x63993c90,0x63bc0000)
to space 3328K, 0% used [0x63540000,0x63540000,0x63880000)
ParOldGen total 843776K, used 423618K [0x23bc0000, 0x573c0000, 0x573c0000)
object space 843776K, 50% used [0x23bc0000,0x3d970b18,0x573c0000)
PSPermGen total 262144K, used 51848K [0x03bc0000, 0x13bc0000, 0x23bc0000)
object space 262144K, 19% used [0x03bc0000,0x06e62138,0x13bc0000)
}
Event: 572351.132 GC heap before
{Heap before GC invocatiOns=5047 (full 357):
PSYoungGen total 201472K, used 199247K [0x573c0000, 0x63bc0000, 0x63bc0000)
eden space 198144K, 100% used [0x573c0000,0x63540000,0x63540000)
from space 3328K, 33% used [0x63880000,0x63993c90,0x63bc0000)
to space 3328K, 0% used [0x63540000,0x63540000,0x63880000)
ParOldGen total 843776K, used 423618K [0x23bc0000, 0x573c0000, 0x573c0000)
object space 843776K, 50% used [0x23bc0000,0x3d970b18,0x573c0000)
PSPermGen total 262144K, used 51848K [0x03bc0000, 0x13bc0000, 0x23bc0000)
object space 262144K, 19% used [0x03bc0000,0x06e62138,0x13bc0000)
Event: 572351.137 GC heap after
Heap after GC invocatiOns=5047 (full 357):
PSYoungGen total 201472K, used 1615K [0x573c0000, 0x63bc0000, 0x63bc0000)
eden space 198144K, 0% used [0x573c0000,0x573c0000,0x63540000)
from space 3328K, 48% used [0x63540000,0x636d3ec8,0x63880000)
to space 3328K, 0% used [0x63880000,0x63880000,0x63bc0000)
ParOldGen total 843776K, used 423674K [0x23bc0000, 0x573c0000, 0x573c0000)
object space 843776K, 50% used [0x23bc0000,0x3d97eb18,0x573c0000)
PSPermGen total 262144K, used 51848K [0x03bc0000, 0x13bc0000, 0x23bc0000)
object space 262144K, 19% used [0x03bc0000,0x06e62138,0x13bc0000)
}
Event: 572398.649 GC heap before
{Heap before GC invocatiOns=5048 (full 357):
PSYoungGen total 201472K, used 199759K [0x573c0000, 0x63bc0000, 0x63bc0000)
eden space 198144K, 100% used [0x573c0000,0x63540000,0x63540000)
from space 3328K, 48% used [0x63540000,0x636d3ec8,0x63880000)
to space 3328K, 0% used [0x63880000,0x63880000,0x63bc0000)
ParOldGen total 843776K, used 423674K [0x23bc0000, 0x573c0000, 0x573c0000)
object space 843776K, 50% used [0x23bc0000,0x3d97eb18,0x573c0000)
PSPermGen total 262144K, used 51848K [0x03bc0000, 0x13bc0000, 0x23bc0000)
object space 262144K, 19% used [0x03bc0000,0x06e62138,0x13bc0000)
Event: 572398.655 GC heap after
Heap after GC invocatiOns=5048 (full 357):
PSYoungGen total 201472K, used 1998K [0x573c0000, 0x63bc0000, 0x63bc0000)
eden space 198144K, 0% used [0x573c0000,0x573c0000,0x63540000)
from space 3328K, 60% used [0x63880000,0x63a73830,0x63bc0000)
to space 3328K, 0% used [0x63540000,0x63540000,0x63880000)
ParOldGen total 843776K, used 423703K [0x23bc0000, 0x573c0000, 0x573c0000)
object space 843776K, 50% used [0x23bc0000,0x3d985cc0,0x573c0000)
PSPermGen total 262144K, used 51848K [0x03bc0000, 0x13bc0000, 0x23bc0000)
object space 262144K, 19% used [0x03bc0000,0x06e62138,0x13bc0000)
}
Event: 576881.689 GC heap before
{Heap before GC invocatiOns=5049 (full 357):
PSYoungGen total 201472K, used 200142K [0x573c0000, 0x63bc0000, 0x63bc0000)
eden space 198144K, 100% used [0x573c0000,0x63540000,0x63540000)
from space 3328K, 60% used [0x63880000,0x63a73830,0x63bc0000)
to space 3328K, 0% used [0x63540000,0x63540000,0x63880000)
ParOldGen total 843776K, used 423703K [0x23bc0000, 0x573c0000, 0x573c0000)
object space 843776K, 50% used [0x23bc0000,0x3d985cc0,0x573c0000)
PSPermGen total 262144K, used 51850K [0x03bc0000, 0x13bc0000, 0x23bc0000)
object space 262144K, 19% used [0x03bc0000,0x06e62850,0x13bc0000)
Event: 576881.696 GC heap after
Heap after GC invocatiOns=5049 (full 357):
PSYoungGen total 201472K, used 3155K [0x573c0000, 0x63bc0000, 0x63bc0000)
eden space 198144K, 0% used [0x573c0000,0x573c0000,0x63540000)
from space 3328K, 94% used [0x63540000,0x63854cb0,0x63880000)
to space 3328K, 0% used [0x63880000,0x63880000,0x63bc0000)
ParOldGen total 843776K, used 423703K [0x23bc0000, 0x573c0000, 0x573c0000)
object space 843776K, 50% used [0x23bc0000,0x3d985cc0,0x573c0000)
PSPermGen total 262144K, used 51850K [0x03bc0000, 0x13bc0000, 0x23bc0000)
object space 262144K, 19% used [0x03bc0000,0x06e62850,0x13bc0000)
}
Event: 580535.452 GC heap before
{Heap before GC invocatiOns=5050 (full 357):
PSYoungGen total 201472K, used 201299K [0x573c0000, 0x63bc0000, 0x63bc0000)
eden space 198144K, 100% used [0x573c0000,0x63540000,0x63540000)
from space 3328K, 94% used [0x63540000,0x63854cb0,0x63880000)
to space 3328K, 0% used [0x63880000,0x63880000,0x63bc0000)
ParOldGen total 843776K, used 423703K [0x23bc0000, 0x573c0000, 0x573c0000)
object space 843776K, 50% used [0x23bc0000,0x3d985cc0,0x573c0000)
PSPermGen total 262144K, used 51856K [0x03bc0000, 0x13bc0000, 0x23bc0000)
object space 262144K, 19% used [0x03bc0000,0x06e64228,0x13bc0000)
Event: 580535.459 GC heap after
Heap after GC invocatiOns=5050 (full 357):
PSYoungGen total 200960K, used 1858K [0x573c0000, 0x63bc0000, 0x63bc0000)
eden space 197632K, 0% used [0x573c0000,0x573c0000,0x634c0000)
from space 3328K, 55% used [0x63880000,0x63a50be0,0x63bc0000)
to space 3584K, 0% used [0x634c0000,0x634c0000,0x63840000)
ParOldGen total 843776K, used 423703K [0x23bc0000, 0x573c0000, 0x573c0000)
object space 843776K, 50% used [0x23bc0000,0x3d985cc0,0x573c0000)
PSPermGen total 262144K, used 51856K [0x03bc0000, 0x13bc0000, 0x23bc0000)
object space 262144K, 19% used [0x03bc0000,0x06e64228,0x13bc0000)
}

看了上面的内容,并没有发现tomcat闪崩是由于老年代,持久代,新生代空间不足引起的。有好几次因为eden区空间使用到100%引起的full gc,但是垃圾回收过后eden区的空间都恢复到正常的水平。

日志中还记录了tomcat闪崩时heap堆的使用情况:

Heap
PSYoungGen total 200960K, used 95671K [0x573c0000, 0x63bc0000, 0x63bc0000)
eden space 197632K, 47% used [0x573c0000,0x5cf5d230,0x634c0000)
from space 3328K, 55% used [0x63880000,0x63a50be0,0x63bc0000)
to space 3584K, 0% used [0x634c0000,0x634c0000,0x63840000)
ParOldGen total 843776K, used 423703K [0x23bc0000, 0x573c0000, 0x573c0000)
object space 843776K, 50% used [0x23bc0000,0x3d985cc0,0x573c0000)
PSPermGen total 262144K, used 51856K [0x03bc0000, 0x13bc0000, 0x23bc0000)
object space 262144K, 19% used [0x03bc0000,0x06e64228,0x13bc0000)

一切都那么正常,同时又那么诡异。

翻看了之前发生日志,内容都是大同小异。

重新翻看了几遍日志,这次把重点放在日志中建议的解决方案上:

# Reduce memory load on the system
# Increase physical memory or swap space
# Check if swap backing store is full
# Use 64 bit Java on a 64 bit OS
# Decrease Java heap size (-Xmx/-Xms)
# Decrease number of Java threads
# Decrease Java thread stack sizes (-Xss)

其中下面几个解决方案不采用:

  • Reduce memory load on the system。 系统内存够用,32G的内存,还剩20G没用,无需减少内存。
  • Increase physical memory or swap space。 系统内存够用,32G的内存,还剩20G没用,无需增加物理内存。
  • Use 64 bit Java on a 64 bit OS。 32位操作系统,无法使用64位jdk。

只剩下下面的三个解决方案了:

  • Decrease Java heap size (-Xmx/-Xms)。 heap堆设置过大,就会影响剩余内存。
  • Decrease number of Java threads
  • Decrease Java thread stack sizes (-Xss)

而减少java线程的数量,需要修改代码,这个也不实际。

最后只剩下

  • Decrease Java heap size (-Xmx/-Xms)
  • Decrease Java thread stack sizes (-Xss)

这两个解决方案了,就从这里入手,曙光就在前方。

先看 Decrease Java thread stack sizes (-Xss) 解决方案

java线程运行也是需要内存空间的,-Xss参数指定每个线程堆栈的大小,为jvm启动的每个线程分配的内存大小。在jdk1.4版本中是256K,JDK1.5及以上版本是1M。

tomcat jvm的参数设置如下:

JAVA_OPTS=%JAVA_OPTS% -server -Xms1024m -Xmx1024m -Xmn200M -XX:PermSize=256M -XX:MaxPermSize=512m -XX:SurvivorRatio=1 -Xss256k

已经通过-Xss设置每个java线程堆栈的大小为256K。

在java语言里, 当你创建一个线程的时候,虚拟机会在JVM内存创建一个Thread对象同时创建一个操作系统线程,而这个系统线程的内存用的不是JVMMemory,而是系统中剩下的内存(MaxProcessMemory - JVMMemory - ReservedOsMemory)。

当需要创建线程,而操作系统剩余内存不够分配给一个java线程时,就会报Out of Memory Error的错误。

由于已经设置通过-Xss设置java线程栈的大小为256K,因此也决定不采用这个解决方案。

现在只剩 下Decrease Java heap size (-Xmx/-Xms) 这个解决方案了。通过减少堆的大小,而留出足够的内存空间给java线程堆栈使用。

32位的window操作系统给每个进程分配的内存空间是2G,减去堆的最大容量和PermSize的最大容量,剩下的容量就留给java线程栈使用。

经过分析代码和之前错误的日志,发现一般在350个线程这样就出现Out of Memory Error的错误。
在出现错误时,heap空间才用了不到40%。因此决定将java heap的从1G减少到768M。

修改的jvm参数如下:

JAVA_OPTS=%JAVA_OPTS% -server -Xms768m -Xmx768m -Xmn200M -XX:PermSize=256M -XX:MaxPermSize=512m -XX:SurvivorRatio=1 -Xss256k

到目前为止,系统已经稳定运行1个月,各个参数指标都在正常范围内。heap使用率最高才70%。

总结:

1、经过这次解决bug,加深了对java虚拟机的了解,特别是线程栈,内存堆,持久代,新生代等概念。

2、一定要仔细阅读日志文件,一步一步排除掉潜在的解决方案。综合系统的运行环境,找出合理的解决方案。

好了,以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对的支持。


推荐阅读
  • 在IDEA中运行CAS服务器的配置方法
    本文介绍了在IDEA中运行CAS服务器的配置方法,包括下载CAS模板Overlay Template、解压并添加项目、配置tomcat、运行CAS服务器等步骤。通过本文的指导,读者可以轻松在IDEA中进行CAS服务器的运行和配置。 ... [详细]
  • 本文介绍了在Hibernate配置lazy=false时无法加载数据的问题,通过采用OpenSessionInView模式和修改数据库服务器版本解决了该问题。详细描述了问题的出现和解决过程,包括运行环境和数据库的配置信息。 ... [详细]
  • 如何实现织梦DedeCms全站伪静态
    本文介绍了如何通过修改织梦DedeCms源代码来实现全站伪静态,以提高管理和SEO效果。全站伪静态可以避免重复URL的问题,同时通过使用mod_rewrite伪静态模块和.htaccess正则表达式,可以更好地适应搜索引擎的需求。文章还提到了一些相关的技术和工具,如Ubuntu、qt编程、tomcat端口、爬虫、php request根目录等。 ... [详细]
  • 本文介绍了如何使用C#制作Java+Mysql+Tomcat环境安装程序,实现一键式安装。通过将JDK、Mysql、Tomcat三者制作成一个安装包,解决了客户在安装软件时的复杂配置和繁琐问题,便于管理软件版本和系统集成。具体步骤包括配置JDK环境变量和安装Mysql服务,其中使用了MySQL Server 5.5社区版和my.ini文件。安装方法为通过命令行将目录转到mysql的bin目录下,执行mysqld --install MySQL5命令。 ... [详细]
  • Oracle优化新常态的五大禁止及其性能隐患
    本文介绍了Oracle优化新常态中的五大禁止措施,包括禁止外键、禁止视图、禁止触发器、禁止存储过程和禁止JOB,并分析了这些禁止措施可能带来的性能隐患。文章还讨论了这些禁止措施在C/S架构和B/S架构中的不同应用情况,并提出了解决方案。 ... [详细]
  • MySQL语句大全:创建、授权、查询、修改等【MySQL】的使用方法详解
    本文详细介绍了MySQL语句的使用方法,包括创建用户、授权、查询、修改等操作。通过连接MySQL数据库,可以使用命令创建用户,并指定该用户在哪个主机上可以登录。同时,还可以设置用户的登录密码。通过本文,您可以全面了解MySQL语句的使用方法。 ... [详细]
  • 分享css中提升优先级属性!important的用法总结
    web前端|css教程css!importantweb前端-css教程本文分享css中提升优先级属性!important的用法总结微信门店展示源码,vscode如何管理站点,ubu ... [详细]
  • 如何实现JDK版本的切换功能,解决开发环境冲突问题
    本文介绍了在开发过程中遇到JDK版本冲突的情况,以及如何通过修改环境变量实现JDK版本的切换功能,解决开发环境冲突的问题。通过合理的切换环境,可以更好地进行项目开发。同时,提醒读者注意不仅限于1.7和1.8版本的转换,还要适应不同项目和个人开发习惯的需求。 ... [详细]
  • Servlet多用户登录时HttpSession会话信息覆盖问题的解决方案
    本文讨论了在Servlet多用户登录时可能出现的HttpSession会话信息覆盖问题,并提供了解决方案。通过分析JSESSIONID的作用机制和编码方式,我们可以得出每个HttpSession对象都是通过客户端发送的唯一JSESSIONID来识别的,因此无需担心会话信息被覆盖的问题。需要注意的是,本文讨论的是多个客户端级别上的多用户登录,而非同一个浏览器级别上的多用户登录。 ... [详细]
  • 开发笔记:spring boot项目打成war包部署到服务器的步骤与注意事项
    本文介绍了将spring boot项目打成war包并部署到服务器的步骤与注意事项。通过本文的学习,读者可以了解到如何将spring boot项目打包成war包,并成功地部署到服务器上。 ... [详细]
  • SpringMVC工作流程概述
    SpringMVC工作流程概述 ... [详细]
  • 项目运行环境配置及可行性分析
    本文介绍了项目运行环境配置的要求,包括Jdk1.8、Tomcat7.0、Mysql、HBuilderX等工具的使用。同时对项目的技术可行性、操作可行性、经济可行性、时间可行性和法律可行性进行了分析。通过对数据库的设计和功能模块的设计,确保系统的完整性和安全性。在系统登录、系统功能模块、管理员功能模块等方面进行了详细的介绍和展示。最后提供了JAVA毕设帮助、指导、源码分享和调试部署的服务。 ... [详细]
  • Tomcat安装与配置教程及常见问题解决方法
    本文介绍了Tomcat的安装与配置教程,包括jdk版本的选择、域名解析、war文件的部署和访问、常见问题的解决方法等。其中涉及到的问题包括403问题、数据库连接问题、1130错误、2003错误、Java Runtime版本不兼容问题以及502错误等。最后还提到了项目的前后端连接代码的配置。通过本文的指导,读者可以顺利完成Tomcat的安装与配置,并解决常见的问题。 ... [详细]
  • Linux下部署Symfoy2对app/cache和app/logs目录的权限设置,symfoy2logs
    php教程|php手册xml文件php教程-php手册Linux下部署Symfoy2对appcache和applogs目录的权限设置,symfoy2logs黑色记事本源码,vsco ... [详细]
  • nginx+多个tomcat
    学习nginx的时候遇到的问题:nginx怎么部署两台tomcat?upstream在网上找的资源,我在nginx配置文件(nginx.conf)中添加了两个server。结果只显 ... [详细]
author-avatar
手机用户250285627
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有