Sagemaker连EMR配置spark.yarn.dist.archives报JRE内存不足排查

/tmp/hs_err_pid24900.log 存放在崩溃发生时对应的JVM所在节点，你这个场景下会话还未运行任何业务代码、未启动Spark Driver/Executor，崩溃的是Livy服务端进程，所以该日志在Livy Server部署的节点上，不在EMR的Core/Task计算节点，也不在你使用的SageMaker实例上。没有Livy节点权限的话不需要找这个日志，通过后续的调试方法不用登录节点就能定位问题。

你之前调整spark.driver.memory、spark.executor.memory参数无效是正常的，因为这两个参数只控制YARN上启动的Spark进程内存，和崩溃的Livy进程无关。
spark.yarn.dist.archives触发崩溃的核心逻辑如下：

• Livy收到创建会话的请求后，会先在自身进程内完成所有分发资源的预校验、本地缓存、预解压操作，这一步在Spark Driver提交到YARN之前执行，所有内存消耗都算在Livy服务端JVM的内存配额里，不受你传入的Spark内存参数控制。
• 你分发的conda环境tar包如果体积过大，Livy在做内存映射解压、网络拉取缓存的时候会申请大量堆外内存，一旦超过Livy进程预设的内存上限、或者所在节点的cgroup内存限制，就会触发JVM native内存分配失败，直接导致会话进程死亡。
• 移除spark.yarn.dist.archives配置后，Livy不需要处理大体积归档资源，内存占用极低，哪怕你把Spark Driver/Executor内存设得很高，也不会触发Livy端的内存瓶颈，和集群本身的剩余内存多少没有关系。

• 优先精简conda环境压缩包：打包前执行conda clean -afy清理所有安装缓存，删除环境内的文档、测试用例、__pycache__目录、非运行必须的大体积依赖（比如GUI相关包、示例数据集），正常用于PySpark的conda环境压缩后可以控制在1G以内，绝大多数场景下精简到这个体积就能直接解决问题。
• 绕开Livy的archives预解压逻辑：把conda压缩包从spark.yarn.dist.archives挪到spark.yarn.dist.files配置项，通过Spark任务启动前的初始化脚本手动执行解压操作，这样Livy只会做普通文件的分发校验，不会触发大体积归档的预解压内存占用，实测可以把Livy端的相关内存消耗降低90%以上。
• 添加会话配置降低Livy预校验开销：配置spark.yarn.archive.localDirCheck=false关闭归档包的本地目录预检查，配置spark.yarn.stagingDir指向你有权限的对象存储路径，减少Livy本地磁盘临时缓存的内存映射开销。

• 不需要登录集群节点拿错误日志，在sparkmagic的会话配置中添加livy.session.debug=true，会话启动失败后返回的日志会直接带出Livy端的执行栈，可以明确看到崩溃前是在执行资源拉取还是解压操作。
• 做最小化对照测试：准备一个几KB大小的测试tar包配置到spark.yarn.dist.archives中，如果会话能正常启动，就可以100%确认问题是conda包体积过大触发的Livy端内存限制，和Spark侧、YARN侧的配置无关。
• 逐步增大测试压缩包的体积，找到当前Livy实例可支持的最大归档包阈值，后续生产使用的环境包体积不要超过该阈值即可。

内容的提问来源于stack exchange，提问作者Luis Leal