Go 服务遇到 too many open files 怎么办：FD 增长定位、修复与回退

凌晨的 Go 网关日志里突然出现 accept4: too many open files，重启后请求就恢复正常，这个现象很容易把排查思路直接带向“把 ulimit -n 调大”的捷径上。更稳妥的做法是先确认进程的文件描述符（FD）是否持续增长，再把增长来源分成 TCP 连接、普通文件、管道和事件句柄几类，补全资源生命周期的关闭逻辑后复查曲线，最后才决定是否调整上限。

遇到这类报错不要直接把系统FD上限拉满，优先定位泄漏点补全资源关闭逻辑，确认资源曲线稳定后再按需调整上限，同时配套告警和回退方案。

先确认是进程本身耗尽，还是服务管理器没传对上限

同一台机器上，终端里执行 ulimit -n 得到的只是当前 shell 会话的限制。Go 服务如果由 systemd、容器或其他进程管理器拉起，实际生效的限制值要以进程自己的配置为准。先记下 PID 和采样时间，再做一次基线记录：

pid=$(pgrep -xo order-gateway)
printf 'pid=%s\n' "$pid"
cat "/proc/$pid/limits" | grep -i 'open files'
printf 'fd_count='
find "/proc/$pid/fd" -maxdepth 1 -type l | wc -l

如果 FD 数量已经接近软上限，但业务连接数没有同步增加，优先怀疑文件、管道或连接存在未释放的泄漏。如果当前上限只有 1024，而服务稳定运行时已经需要几千条长连接，则需要先评估整体容量，再在服务管理配置里有计划地提升，而不是只改当前终端的临时值。

用 /proc 和 lsof 把 FD 增长分成四类排查

只看 FD 总数值很难定位问题。连续采样两三次，每次间隔 30 秒，观察总数和各类型占比是否同步上涨。下面的命令会把进程打开的对象按类型列出来：

lsof -nP -p "$pid" | awk 'NR > 1 {print $5}' | sort | uniq -c | sort -nr
lsof -nP -a -p "$pid" -iTCP | sed -n '1,20p'
ls -l "/proc/$pid/fd" | sed -n '1,20p'

网络 socket 占比高时，先查关闭路径和连接复用逻辑

Go HTTP 客户端开发里最常见的误判是：请求已经返回，就认为 socket 会自动回收。对需要读取响应内容的请求，调用方必须主动关闭 resp.Body；如果只读取一部分内容就直接返回，还可能破坏连接复用逻辑。服务端长连接则要额外核对 keep-alive 配置、超时规则和客户端是否真的正常断开。

func fetch(ctx context.Context, client *http.Client, url string) ([]byte, error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil { return nil, err }
    resp, err := client.Do(req)
    if err != nil { return nil, err }
    defer resp.Body.Close()
    body, err := io.ReadAll(io.LimitReader(resp.Body, 2= http.StatusBadRequest {
        return nil, fmt.Errorf("upstream status %d", resp.StatusCode)
    }
    return body, nil
}

这里的检查点不是“加一行 Close 调用就结束”。可以用 pprof 看 goroutine 是否卡在下游读写环节，再用 lsof 持续观察 socket 数量变化。如果响应体已经正确关闭，但大量连接长期处于 CLOSE_WAIT，要继续排查服务端或代理的断开通知机制；如果是 ESTABLISHED 数值持续上涨，则重点关注连接池上限和请求超时配置。

普通文件和管道泄漏，要盯住异常错误分支

文件泄漏往往不是主流程造成的，而是“打开文件后，后续参数校验失败”这条分支忘了关闭资源。把关闭动作放在确认打开成功之后、紧邻打开操作的位置，代码评审时就能很清晰看出资源归属：

func readConfig(path string) ([]byte, error) {
    file, err := os.Open(path)
    if err != nil { return nil, err }
    defer file.Close()
    return io.ReadAll(io.LimitReader(file, 1

不要用“每次定时任务结束时统一清理”的逻辑替代局部关闭操作。统一清理通常意味着资源会在整个周期内持续堆积，遇到并发任务场景就更难判断是哪个逻辑留下的泄漏。如果服务会调用外部命令或 sidecar 组件，还要记录子进程 PID、退出状态和 pipe 关闭动作，避免只关闭管道一端。

修复后怎么复查，什么场景下允许上调上限

修复代码并重启服务后，先用相同的采样命令观察 10 到 15 分钟。理想结果不是 FD 数值立刻降到很低，而是流量回到正常水平后曲线进入平稳区间，没有每分钟固定上涨的斜率。

for i in 1 2 3 4 5; do
  date '+%H:%M:%S'
  find "/proc/$pid/fd" -maxdepth 1 -type l | wc -l
  sleep 30
done

临时提升上限可以给问题修复争取缓冲时间，但必须同时配套设置告警规则。比如软上限设为 65536 时，在使用率到 70% 时触发提醒、85% 时进入人工确认流程；如果 FD 还在持续上涨，不要用更大的上限数字掩盖泄漏问题。回退时恢复 systemd 的 LimitNOFILE 或容器的对应限制配置，并确认滚动重启后的新进程继承了预期的限制值。

把这次故障变成可复用的告警和复盘项

监控里至少要保留进程 FD 使用量、软上限占比、TCP 连接状态和请求错误率四条核心曲线。单独监控 too many open files 的日志通常已经太晚，比例类告警能在 accept 失败之前就给出足够的缓冲时间。

复盘时把“谁打开、谁关闭、关闭失败怎么兜底”的规则写到对应接口或函数的责任边界里；新增 HTTP 客户端、日志切割器和子进程管道逻辑时，补一个高并发或重复调用场景的测试用例。这样下次看到 FD 上涨，直接按对象分类和采样曲线排查，不必从重启服务开始兜圈子。

相关问题

只调大 ulimit 能彻底解决 too many open files 吗？

不能。它只能扩大可用额度，不能修复资源持续泄漏的问题。只有在确认 FD 曲线稳定、业务确实需要更多长连接时，才适合配合容量评估做调整。

为什么 Go 服务重启后问题会暂时消失？

重启会关闭进程持有的所有文件、socket 和管道，所以计数会直接归零；如果代码逻辑没有改动，流量恢复后泄漏会再次出现。

lsof 没装时还能怎么查？

可以直接读取 /proc//fd 和 /proc//net/tcp，先确认数量与对象类型，再决定是否补装诊断工具。

小结

处理 too many open files 的关键不是记住某个固定上限数字，而是建立“进程限制 → FD 类型 → 代码关闭点 → 修复后曲线验证”的完整证据链。把上限调整作为带告警、带回退的容量操作，才能避免服务每隔几天就得靠重启续命。