Spark 2.4.0 Master节点运行1-2小时后宕机问题求助

从你描述的场景和给出的异常栈来看，核心问题是RpcTimeoutException：Master节点（192.168.43.167:40007）在120秒内无法收到Executor的响应，这个超时由spark.rpc.askTimeout参数控制。结合你提到的“Spark 2.1.1无问题，升级到2.4.0后出现”的情况，大概率是新版本在RPC通信、资源管理或Kafka流处理逻辑上的变化导致的。下面是具体的排查和解决步骤：

异常详情 #

Exception in thread "main" java.lang.reflect.UndeclaredThrowableException
at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1713)
at org.apache.spark.deploy.SparkHadoopUtil.runAsSparkUser(SparkHadoopUtil.scala:64)
at org.apache.spark.executor.CoarseGrainedExecutorBackend$.run(CoarseGrainedExecutorBackend.scala:188)
at org.apache.spark.executor.CoarseGrainedExecutorBackend$.main(CoarseGrainedExecutorBackend.scala:281)
at org.apache.spark.executor.CoarseGrainedExecutorBackend.main(CoarseGrainedExecutorBackend.scala)
Caused by: org.apache.spark.rpc.RpcTimeoutException: Cannot receive any reply from 192.168.43.167:40007 in 120 seconds. This timeout is controlled by spark.rpc.askTimeout
at org.apache.spark.rpc.RpcTimeout.org$apache$spark$rpc$RpcTimeout$$createRpcTimeoutException(RpcTimeout.scala:47)
...
Caused by: java.util.concurrent.TimeoutException: Cannot receive any reply from 192.168.43.167:40007 in 120 seconds

解决步骤 #

1. 调整RPC相关超时参数 #

Spark 2.4.0对RPC通信的超时控制更严格，默认120秒可能不足以应对Master/Executor之间的延迟。在你的Spark配置中添加以下参数：

spark.rpc.askTimeout=300s          # 调大RPC请求的超时时间
spark.rpc.lookupTimeout=300s       # 服务发现的超时时间同步调整
spark.network.timeout=300s         # 全局网络超时，覆盖心跳、数据传输等场景
spark.executor.heartbeatInterval=10s  # 缩短Executor向Master发送心跳的间隔，让Master更快感知Executor状态

2. 优化Master节点资源配置 #

Spark 2.4.0的Master进程可能比2.1.1占用更多内存/CPU，尤其是同时运行4个流应用时，容易因资源耗尽宕机。修改Master的启动参数：

• 调大Master的JVM堆内存，比如在spark-env.sh中设置：

  export SPARK_MASTER_OPTS="-Xmx4g -XX:+UseG1GC"  # 从默认1G提升到4G，同时使用G1垃圾收集器减少停顿
  

• 监控Master节点的CPU、内存使用率，确认是否有资源瓶颈。

3. 调整Executor资源与GC配置 #

Executor无法及时响应Master的RPC请求，可能是自身资源不足或GC停顿过长导致：

• 合理分配Executor资源，比如：

  spark.executor.memory=8g
  spark.executor.cores=4
  spark.executor.instances=8  # 根据集群资源调整，避免单个Executor负载过高
  

• 开启GC日志排查问题，添加JVM参数：

  export SPARK_EXECUTOR_OPTS="-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:/path/to/gc.log"
  

  如果发现长时间Full GC，考虑调整GC策略（比如改用G1GC）或增加Executor内存。

4. 优化Kafka Direct Stream配置 #

Spark 2.4.0的Kafka Direct API有一些内部优化，可能引发阻塞问题：

• 启用背压机制，防止突发流量压垮系统：

  spark.streaming.backpressure.enabled=true
  spark.streaming.backpressure.initialRate=100  # 根据实际消息量调整初始速率
  

• 关闭消费者缓存（如果存在缓存导致的资源泄漏）：

  spark.streaming.kafka.consumer.cache.enabled=false
  

• 检查Kafka偏移量提交逻辑，避免同步提交阻塞流处理：可以改用异步提交，或者调整spark.streaming.kafka.maxRatePerPartition控制每个分区的消费速率。

5. 排查网络稳定性问题 #

RPC超时很多时候是底层网络问题导致的：

• 检查Master与Executor节点之间的网络延迟、丢包率，使用ping、traceroute等工具测试。
• 确认Master的RPC端口（40007）没有被防火墙拦截，且端口未被其他进程占用。
• 检查集群的网络带宽是否足够支撑4个流应用的消息传输。

6. 升级到Spark 2.4.x稳定版本 #

Spark 2.4.0作为大版本初始版本，可能存在一些未修复的bug。建议升级到2.4.x的后期稳定版本（比如2.4.8），这些版本通常修复了大量RPC、资源管理相关的问题。

内容的提问来源于stack exchange，提问作者Lokesh Kumar P