前言
最近一个运行了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、一定要仔细阅读日志文件,一步一步排除掉潜在的解决方案。综合系统的运行环境,找出合理的解决方案。
好了,以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对的支持。
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
RTX 5090要首发 性能要翻倍!三星展示GDDR7显存
三星在GTC上展示了专为下一代游戏GPU设计的GDDR7内存。
首次推出的GDDR7内存模块密度为16GB,每个模块容量为2GB。其速度预设为32 Gbps(PAM3),但也可以降至28 Gbps,以提高产量和初始阶段的整体性能和成本效益。
据三星表示,GDDR7内存的能效将提高20%,同时工作电压仅为1.1V,低于标准的1.2V。通过采用更新的封装材料和优化的电路设计,使得在高速运行时的发热量降低,GDDR7的热阻比GDDR6降低了70%。
更新日志
- [发烧人声]群星《邂逅》DTS-WAV
- 艻打绿《夏/狂热(苏打绿版)》[320K/MP3][106.42MB]
- 艻打绿《夏/狂热(苏打绿版)》[FLAC分轨][574.2MB]
- 黄雨勳《魔法列车首部曲》[320K/MP3][33.1MB]
- 李蕙敏.2014-记得·销魂新歌+精丫乐意唱片】【WAV+CUE】
- 谢金燕.1995-含泪跳恰蔷冠登】【WAV+CUE】
- 于文文.2024-天蝎座【华纳】【FLAC分轨】
- 黄雨勳《魔法列车首部曲》[FLAC/分轨][173.61MB]
- 群星《歌手2024 第13期》[320K/MP3][50.09MB]
- 群星《歌手2024 第13期》[FLAC/分轨][325.93MB]
- 阿木乃《爱情买卖》DTS-ES【NRG镜像】
- 江蕾《爱是这样甜》DTS-WAV
- VA-Hair(OriginalBroadwayCastRecording)(1968)(PBTHAL24-96FLAC)
- 博主分享《美末2RE》PS5 Pro运行画面 玩家仍不买账
- 《双城之战2》超多新歌MV发布:林肯公园再次献声