本文探讨了Spark程序在运行时出现吐核coredump的问题，详细解析了coredump的含义及其在Linux上的形成原理。通过分析driver和executor的日志，发现与系统的xx.so包加载失败及操作系统层面的错误有关。提出了从程序执行步骤入手，查找可能导致巨大内存分配的环节作为解决策略。同时，强调了分析coredump文件以定位JVM问题的重要性，但该过程复杂。
提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档
spark core dump问题分析
spark 程序 出现吐核 core dump报错
一、报错信息
driver日志： 报错吐核
挂掉的executor日志
nodeManager日志：（报错，吐核）
Internal Error (sharedRuntime.cpp:834), pid=***, tid=***
fatal error: exception happened outside interpreter, nmethods and vtable stubs at pc ***
下图日志：看上去是操作系统的*.so包的版本不匹配
二、分析思路
1.想确定什么是core dump,什么是吐核
Linux上Core Dump文件的形成和分析
https://www.cnblogs.com/jefree/p/4439034.html
Core，又称之为Core Dump文件，是Unix/Linux操作系统的一种机制，对于线上服务而言，Core令人闻之色变，因为出Core的过程意味着服务暂时不能正常响应，需要恢复，并且随着吐Core进程的内存空间越大，此过程可能持续很长一段时间（例如当进程占用60G+以上内存时，完整Core文件需要15分钟才能完全写到磁盘上），这期间产生的流量损失，不可估量。
凡事皆有两面性，OS在出Core的同时，虽然会终止掉当前进程，但是也会保留下第一手的现场数据，OS仿佛是一架被按下快门的相机，而照片就是产出的Core文件。里面含有当进程被终止时内存、CPU寄存器等信息，可以供后续开发人员进行调试。
关于Core产生的原因很多，比如过去一些Unix的版本不支持现代Linux上这种GDB直接附着到进程上进行调试的机制，需要先向进程发送终止信号，然后用工具阅读core文件。在Linux上，我们就可以使用kill向一个指定的进程发送信号或者使用gcore命令来使其主动出Core并退出。如果从浅层次的原因上来讲，出Core意味着当前进程存在BUG，需要程序员修复。从深层次的原因上讲，是当前进程触犯了某些OS层级的保护机制，逼迫OS向当前进程发送诸如SIGSEGV(即signal 11)之类的信号, 例如访问空指针或数组越界出Core，实际上是触犯了OS的内存管理，访问了非当前进程的内存空间，OS需要通过出Core来进行警示，这就好像一个人身体内存在病毒，免疫系统就会通过发热来警示，并导致人体发烧是一个道理（有意思的是，并不是每次数组越界都会出Core，这和OS的内存管理中虚拟页面分配大小和边界有关，即使不出Core，也很有可能读到脏数据，引起后续程序行为紊乱，这是一种很难追查的BUG）。
2.问题分析思路
按照文章中讲的： core dump是JVM出现问题后，事故保存现场的方法。就像heap dump一样。那么如果要知道准确的jvm问题，就需要分析core dump文件，而分析core dump文件很复杂。所以，知道是程序有问题后，就好解决，排查目前spark作业执行到哪步，分析这一步哪里需要分配巨大的堆内存或者栈内存，就能解决问题
总结
提示：这里对文章进行总结：
core dump是JVM出现问题后，事故保存现场的方法。就像heap dump一样。那么如果要知道准确的jvm问题，就需要分析core dump文件，而分析core dump文件很复杂。所以，知道是程序有问题后，就好解决，排查目前spark作业执行到哪步，分析这一步哪里需要分配巨大的堆内存或者栈内存，就能解决问题
扫一扫
2190
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
