IBM AIX平台的内存溢出案例分析
同样,某客户Oracle Agile PLM的集群服务器中的一个节点突然crash掉,在javacore(Thread Dump)中记录了java/lang/OutOfMemoryError错误,没有Heap Dump,只有GC日志。
系统环境如下:
javacore的头部信息显示为 systhrow,运行时错误捕获为OutOfMemory,注意,不是异常。
1TISIGINFO Dump Event "systhrow" (00040000) Detail "java/lang/OutOfMemoryError" received
线程日志记录了GC的产生,至于Heap Dump日志因为文件太庞大,客户没有提供。在分析GC之前,先查看内存堆的分配。
0SECTION MEMINFO subcomponent dump routineNULL =================================1STHEAPFREE Bytes of Heap Space Free: 1276948 1STHEAPALLOC Bytes of Heap Space Allocated: 80000000
分配给JVM的内存堆有80000000即2G,而可用的空闲heap只有1276948即19M,理所当然的内存溢出。
借助GC分析工具,可以查看free heap的分配情况。在内存回收之前 
回收之后 
再看回收之后所持有的内存 
虽然heap有所缓解,但是free heap整体在减少,而且减少的相当快。大量被占用的内存无法回收。
客户没有提供Heap Dump日志,但是基本上已经找出内存为何泄漏的原因。客户的集群服务中有一台node,同时部署了其他的application,而内存泄漏正是由这个application产生,这也就是为什么分配的JVM为2G,但该application最高占用才900M的原因。
建议客户产生Heap Dump,自行分析究竟是哪条java线程耗用内存。具体方法如下:
1. 设置Heap Dump变量
export IBM_HEAPDUMP=trueexport IBM_HEAP_DUMP=trueexport IBM_HEAPDUMP_OUTOFMEMORY=trueexport IBM_HEAPDUMPDIR=[directory path here]
2. 发送User事件
kill -3 [PID]
在相应的路径下会有*.phd文件记录各java线程的内存分配。