一台linux服务器配置8G内存,这台服务器上通过WAS就部署了一个Server,JVM里的初始堆大小和最大堆大小均设置成2G,部署的应用属于高频访问应用,几乎每个月都会发生3到5次OOM,影响系统访问。
通过IBM的dump文件分析工具,定位可能dwr写法有问题,但经整个项目组排查分析并没有发现代码层面有明显缺陷。想增加jvm的堆大小,但是系统管理员说,现有的某些比这个系统用户量更大的,都没有比这配置更大的内存。
各位大牛有何高招?
1、代码方面:弱眼看不出来的,有没有好的工具结合dump、javacore文件进行代码层面分析?
2、资源方面:如何定义资源瓶颈,如何说服系统管理员加jvm资源?
首先找到OOM的问题症结所在,在发生时的dump文件可以使用IBM的分析工具进行详细分析,如果定位的是参数配置问题则进行调整,如果资源不够,建议出一份对比测试文档说明,比如我说磁盘性能影响我的数据库性能了,从如下逻辑说
1.当前压力下定位瓶颈点在IO,因为nmon监控CPU和内存使用率都很低
2.通过对比机械硬盘和SSD的实际测试数据说明IO的理论倍数
3.通过修改数据库参数配置,进行一些缓存数据等不受IO限制的实际业务测试,根据数据指出当前配置下如果更换SSD的可能理论性能倍数
收起看您的描述已经严重影响应用使用
1、先确认到底是应用存在内存泄漏导致JVM无法回收还是大使用量导致的内存溢出
如果是内存泄漏,增加JVM大小并不会有起效,请改进应用的回收机制
如果是高并发溢出,那就要综合heapdump、 gc日志看是否存在很多大对象、在后端是否处理慢等原因一同考量
不同应用的内存使用量并不是完全由访问量决定,应综合应用占用JVM的代码段及平时使用量等因素一同考量查找使用瓶颈。
IBM 的DUMP工具会直观地看到代码使用内存的情况
收起