​作者​：昇腾实战派
​知识地图​：https://blog.csdn.net/Lumos_Lovegood/article/details/161601003

背景概述

在多机分布式训练场景中，通信域的建立是模型训练启动的关键步骤。近期在模型拉起过程中，遇到了通信域建链耗时异常的问题，表现为建链时间远超预期，严重影响了训练任务的启动效率。本文记录了该问题的现象、排查过程及最终解决方案，供相关开发者参考。

问题现象

模型拉起时，持续报出以下错误信息：

The hostname of the client socket cannot be retrieved. err=-3

同时，创建通信域（建链）的耗时显著增加。通过简化最小通信脚本进行测试，发现在部分环境下多机建链性能严重下降：

• 4机64die 场景：建链耗时约 20分钟
• 2机32die 场景：建链耗时约 10分钟

具体耗时分布如下图所示：

问题排查

1. 官方Issue分析

针对上述报错，PyTorch官方存在对应的 Issue #159007，该问题通过 Pull Request #159596 进行了修复。修复方案为：通过静态变量控制，在 ::getnameinfo 调用失败时仅执行一次，避免因不断重试导致的性能问题。

版本说明：

• 该修复代码仅在 PyTorch 2.9及以上版本 中合入。
• 将修复代码迁移至 PyTorch 2.7.1 版本进行实测，4机64die建链耗时从 20分钟降低至2分钟，优化效果显著。
• 注：::getnameinfo 相关代码通过 Pull Request #136320 在 PyTorch 2.6.0 版本中合入，用于在 onConnect 阶段获取本地地址等信息。PyTorch 2.5及以下版本不受此问题影响。

2. 根因深入分析

上述官方修复仅为规避方案，并非问题的根本原因。继续深入排查，发现以下可能的影响因素：

（1）反向DNS未配置

经检查，环境中确实未配置反向DNS。但对比正常运行的同类环境，发现其同样未配置反向DNS，因此该因素并非直接原因。

（2）客户端使用本地/私有IP

当前为多机场景，不涉及此问题。

（3）DNS服务器不可达

检查发现，环境中配置了类似 8.8.8.8 的DNS服务器地址，但在内网环境中该地址无法连通。进一步对比发现，正常运行的同类环境也存在相同的DNS配置，因此该因素同样不是直接原因。

关键发现：在 /etc/resolv.conf 文件中配置以下选项时，建链耗时显著降低：

options timeout:1 attempts:1 rotate

该配置使得DNS查询在失败时快速返回，且仅重试一次。实测该配置下，4机64die建链耗时控制在 1分钟以内。这是一个有效的规避手段，但并非问题根因。

最终定位：将 /etc/resolv.conf 中错误的DNS服务器配置（如无法ping通的 8.8.8.8）删除后，建链恢复正常，耗时显著缩短。

问题解决方案

根据上述排查结果，提供以下三种解决方案，按推荐优先级排序：

方案一（推荐）：移除错误的DNS配置

检查并删除 /etc/resolv.conf 文件中无法连通或错误的DNS服务器地址（如内网环境中常见的 8.8.8.8）。如果所有配置均为无效地址，可直接备份并删除 /etc/resolv.conf 文件。

方案二：升级PyTorch版本

使用 PyTorch 2.9及以上版本，该版本已合入官方修复，避免 ::getnameinfo 接口的不断重试，显著优化建链性能。

方案三：配置DNS查询参数（临时规避）

在 /etc/resolv.conf 文件中添加以下配置，可有效减少DNS查询失败时的等待时间：

options timeout:1 attempts:1 rotate

该配置可作为一种临时规避手段，但建议优先采用方案一或方案二彻底解决问题。

总结

本文针对多机分布式训练中通信域建链超时的问题，从现象、官方修复、根因分析到解决方案进行了完整梳理。核心问题在于DNS配置错误导致 ::getnameinfo 接口反复重试，进而引发建链耗时异常。通过移除错误DNS配置或升级PyTorch版本，可有效解决该问题，保障训练任务的快速启动。