mysql close_wait_线上大量CLOSE_WAIT原因深入分析

这一次重启真的无法解决问题了：一次 MySQL 主动关闭，导致服务出现大量 CLOSE_WAIT 的全流程排查过程。

近日遇到一个线上服务 socket 资源被不断打满的情况。通过各种工具分析线上问题,定位到问题代码。这里对该问题发现、修复过程进行一下复盘总结。

先看两张图。一张图是服务正常时监控到的 socket 状态，另一张当然就是异常啦！

图一：正常时监控

图二：异常时监控

从图中的表现情况来看，就是从 04:00 开始，socket 资源不断上涨，每个谷底时重启后恢复到正常值，然后继续不断上涨不释放，而且每次达到峰值的间隔时间越来越短。

重启后，排查了日志，没有看到 panic ，此时也就没有进一步检查，真的以为重启大法好。

情况说明

该服务使用Golang开发，已经上线正常运行将近一年，提供给其它服务调用，主要底层资源有DB/Redis/MQ。

为了后续说明的方便，将服务的架构图进行一下说明。

图三：服务架构

架构是非常简单。

问题出现在早上 08:20 左右开始的，报警收到该服务出现 504，此时第一反应是该服务长时间没有重启(快两个月了)，可能存在一些内存泄漏，没有多想直接进行了重启。也就是在图二第一个谷底的时候，经过重启服务恢复到正常水平(重启真好用，开心)。

将近 14:00 的时候，再次被告警出现了 504 ，当时心中略感不对劲，但由于当天恰好有一场大型促销活动，因此先立马再次重启服务。直到后续大概过了1小时后又开始告警，连续几次重启后，发现需要重启的时间间隔越来越短。此时发现问题绝不简单。这一次重启真的解决不了问题老，因此立马申请机器权限、开始排查问题。下面的截图全部来源我的重现demo，与线上无关。

发现问题

出现问题后，首先要进行分析推断、然后验证、最后定位修改。根据当时的表现是分别进行了以下猜想。

ps：后续截图全部来源自己本地复现时的截图

推断一

socket 资源被不断打满，并且之前从未出现过，今日突然出现，怀疑是不是请求量太大压垮服务

经过查看实时 qps 后，放弃该想法，虽然量有增加，但依然在服务器承受范围(远远未达到压测的基准值)。

推断二

两台机器故障是同时发生ÿ