记录一次服务进程强行退出的问题排查过程
場景:我這邊從Hbase跑一億多的全量數據錄入Elasticsearch中,跑了四個多小時,程序突然掛掉了,然后我就納悶了,為啥突然掛掉了???
思路1:是不是Java 進程拋出OOM異常?
 分析程序日志沒有任何異常,如果出現這種異常應該會在日志中打印的啊,怎么沒有呢?
如果是java OOM異常會打印 Java heap space的
Exception in thread "pool-13-thread-25" java.lang.OutOfMemoryError: Java heap space Exception in thread "pool-13-thread-48" java.lang.OutOfMemoryError: Java heap space后來我在JVM參數中添加了-XX:+UnlockExperimentalVMOptions和-XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log看看垃圾回收情況以及如果出現OOM后生成java_pid30796.hprof文件然后利用Jprofile進行分析OOM異常根源,但是發現并沒有出現OOM異常,也沒有dump文件,因而可以確定并不是java OOM異常。
思路2:是不是linux保護機制強制殺死的進程?
 其實一開始沒有看到程序OOM異常日志,就應該想到是linux保護機制強行殺死的,搞的在上面饒了一大圈,浪費太多時間
然后百度,查看最近被linux kill掉的進程信息
 執行命令:dmesg | egrep -i -B100 'killed process'
 輸出:
原因是Low memory耗盡。“內核使用low memory來跟蹤所有的內存分配,一旦low memory耗盡,就會查殺進程,以保持系統的正常運轉。說白了 OOM Killer 就是一層保護機制,用于避免 Linux 在內存不足的時候不至于出太嚴重的問題,把無關緊要的進程殺掉
總結
以上是生活随笔為你收集整理的记录一次服务进程强行退出的问题排查过程的全部內容,希望文章能夠幫你解決所遇到的問題。
 
                            
                        - 上一篇: spark整合MySQL
- 下一篇: sparksql加载mysql表中的数据
