前提:今天前端说接口服务不可用,我先是一顿吐槽,接着不得不承认,确实接口挂了=.=,虚心接受吐槽是一个程序员良好的职业修养,不扯淡,进入正题。
1.查看应用进程:jps -ml (可以看到程序应用名还有 运行环境)
2.重启服务发现可以正常启动。再次执行jps 获取到了进程号pid
3.观察垃圾回收现象 指令:jstat -gc pid 1000 (1s输出一次),发现 EU S0U S1U 这些指标都占用的特别快,这对象增长速度也太快了吧,就发现了问题了,应该是内存溢出系统给进程杀掉了吧。
4.为了验证自己的结论,指令:cat /var/log/message 查了下系统杀掉的进程描述。
5.问题找到了,那就要查是哪些对象占用比较多呢导致的gc这么频繁,用到的指令有:
top -Hp pid 查看该进程站内存高的线程有哪些。然后记住线程的pid(注意这里的pid是十进制的,需要转成十六进制的才能在堆栈信息里使用)
jstack pid 可以查到这个进程下的堆栈信息,然后可以查询之前保留的十六进制的线程pid来查具体原因。我这里的问题是zk注册duboo,watcher实例过多导致的内存溢出
jmap -histo pid 查看该进程里实例对象的个数,然后问题就这样查出来了,后来联系开发人员协助处理zk的坑了。