jvm core

最近遇到一个jvm core(hotspot)的问题,在$HOME目录下生成n多hserr_%pid%.log错误文件,有时候会生成java.core文件。在之前的性能测试和压力测试中均为发现有core file出现,无法手动重现,只有在测试组的自动化测试环境中才能重现。


崩溃的原因并非堆或永久代(元数据区)溢出,异常栈也不规定,有的是在JIT编译过程,有的是在创建线程。

从表象上看是jvm本身崩溃,一般错误日志都指出malloc或mmap函数调用异常(malloc返回null或mmap errno 12),无法申请到内存了。

最一开始怀疑是内存不足引发kernel的OOM killer,后来发现系统的over_commit一直是关闭状态。

于是怀疑是系统内存不足,但是从日志文件可以看到,一般系统都有空闲(free)内存几百MB到2GB不等,最多的一次竟然还有4GB空闲内存,在学习了linux的内存管理之后,依然不理解为何还有空闲内存和swap空闲依然会发生malloc为null和mmap errno12的错误,在测试程序里死循环吃内存也可以重现这种错误。

最后为了揪出吃内存的进程,写了个脚本,监测实时进程统计数据,最后发现是另外一个产品,在重负荷下,起了几十个进程处理数据流,每个进程占用内存40-60MB不等,不由得佩服对面的实力,非常有效的策略,进程启动先把内存申请上,并起一组进程处理大数据流,这样保证本事进程内存可控,又不会被系统杀掉,真是很有经验。

最后是测试方法,测试组的自动化测试设置了8小时的schedule,前后的schedule有重合,导致压力增加,内存不足发生core dump.

如果想知道什么时候系统不再给内存,还需要对内核非常了解才行。

阅读更多
个人分类: java debug
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭