设置JVM内存溢出时快照转存HeapDump到文件
诊断内存溢出是一个有难度的事情,可以在生产环境试一试下面的参数,在发生内存溢出OutOfMemoryError时做HeapDump并保存到文件,然后分析该文件看是否能查到蛛丝马迹。
set JAVA_OPTS=-Xms100m -Xmx192m ^ -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=c:\jakarta-tomcat\webapps
Java Heap Dump文件格式是一个HPROF二进制格式,需要特殊的工具才能进行分析,而这个文件通常都比较大,如果你的Heap Dump文件超过了几百MB,那就不要再寄希望于jhat了,因为jhat需要数倍于dump文件的内存。这个时候你可以用MAT(Memory Analyzer),用MAT你可以在有2GB可用内存的机器上分析大约1GB左右的Dump文件。
周末对ICF平台做了压力测试,具体情况如下:
测试场景:50个并发,持续2小时。
5个人同时登陆,每次提交账号密码后通过检查返回用户信息来检验登陆结果是否成功。
用户登录流程userLogin ,共涉及五个Node节点,分别为,加密用户提交密码、查询操作员信息、判断符合条件的用户是否存在、更新用户最后登陆时间和IP信息、打印结果;对应的处理模块分别为:字符串处理模块(stringUtilMoudle)、普通查询模块(exeQueryModule)、判断模块(ifModule)、数据库更新模块(exeUpdateModule)、Json格式数据输出模块(outputForJson)。
刚开始测试的时候采用Jconsole做堆内存监控发现内存震荡上行,不断上行知道达到我设定的最大值,然后再过一段时间内存就溢出了。
一般的来说有两种情况会出出现这样的问题:1.内存不能满足实际应用需求,也就是并发量或者需要的资源量很大,而服务器不能满足这样的需求。2.存在内存泄露。
于是下一步任务就是获取内存溢出时内存的状态,于是在Tomcat的catalina.bat的虚拟机参数上添加了
set JAVA_OPTS=-Xms1024m -Xmx1024m -XX:PermSize=512M -XX:MaxNewSize=320m -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\heapdump
如上标红的参数,这样就把溢出时,内存快照保存到headdump目录中。有了这个下一步就是要分析当时的情况判断是什么原因引起的内存溢出。
打开MemoryAnalyzer加载内存快照文件,一步步分析内存中的大对象。最后发现是tomcat的session把内存用光了。于是就反过来思考压力测试脚本是不是有问题。检查后发现脚本做请求操作时没有把sessionId 返回给服务器,这样tomcat就为每一次请求都创建一个session对象,结局可想而知。
唉,缺医少药,啥都是问题,于是下一步就变成研究如何在请求中添加sessionid,经过一挺长一段时间摸索,添加上了sessionid,获得了如下的结果.