35000分区Spark作业集群配置建议及shuffle网络报错问题咨询

核心报错根因 #

你遇到的Connection to xxx has been quiet for 120000 ms报错本质是shuffle阶段节点间拉取数据超时，120s无响应被Spark判定为连接失效，该问题和external shuffle服务是否开启无关，核心原因是当前集群配置无法承载shuffle阶段的IO、网络负载，导致请求阻塞超时。

初始问题解答 #

1. 单节点承载分区数推荐值 #

Spark单分区的最优大小区间为128MB_{256MB，对应单节点并行处理的分区数建议不超过节点CPU核心数的2}3倍：

• 你当前3.4TB数据、35000个分区，平均单分区大小约100MB，分区总数量本身没有明显问题
• 你使用的n1-standard-4为4核15GB内存机型，单节点并行处理的分区数建议控制在8~12个，总并行度480的情况下35000个分区排队调度本身没问题，但shuffle阶段单节点需要管理的shuffle块数量过多，会触发IO阻塞进而导致超时。

2. 扩容节点还是升级机型 #

优先升级单节点配置，其次再考虑扩容节点数量：

• n1-standard-4的内存、磁盘IO、网络带宽规格过低，shuffle阶段需要大量内存做缓存、高IO吞吐写临时文件，该机型完全无法支撑大规模shuffle的负载，首先建议更换为n1-standard-8或n2-highmem-8机型，提升单节点内存、网络带宽上限
• 机型升级后如果仍有性能瓶颈，再将节点数扩容到180~200台，降低单节点需要处理的shuffle数据量。

补充问题解答 #

1. 3:00~3:20阶段CPU使用率仅40%的原因 #

该阶段为shuffle write阶段，瓶颈在磁盘IO而非CPU：

• 你测试的128G、256G磁盘写入速度均为4GiB/s，说明磁盘已经达到性能上限，CPU全程等待IO返回，因此使用率无法打满
• 单节点内存过小，shuffle数据无法在内存缓存，必须频繁刷写到磁盘，进一步放大了IO瓶颈，导致CPU空转。

2. 3:20后shuffle read阶段作业失败的排查解决方法 #

临时调优方案

• 调整网络超时参数：设置spark.network.timeout=300s，同步调整spark.shuffle.io.connectionTimeout=300s、spark.shuffle.io.retryWait=30s、spark.shuffle.io.maxRetries=10，避免偶发IO阻塞直接被判定为连接失效
• 调整shuffle分区数：将spark.sql.shuffle.partitions从35000下调到20000左右，将单分区大小提升到170MB区间，减少shuffle块总数量，降低节点元数据管理和IO调度压力
• 开启shuffle压缩：设置spark.shuffle.compress=true、spark.sql.inMemoryColumnarStorage.compressed=true，降低shuffle数据体积，减少网络传输和磁盘IO开销。

永久解决方案

• 更换机型为n2-highmem-8（8核64GB内存），每节点挂载2~4块本地SSD盘，将shuffle目录配置到多块SSD上做IO负载均衡，磁盘IO性能相较普通云盘可提升10倍以上
• 配合external shuffle服务开启Dynamic Resource Allocation，避免shuffle数据随Executor销毁被删除，减少重复计算开销。

内容的提问来源于stack exchange，提问作者Yann Moisan