PHP API偶发MySQL server has gone away错误排查求助

针对你遇到的低概率、仅特定API端点触发的连接错误，按以下方向排查：

1. 定位API端点的特殊行为差异 #

• 记录file_exists()的执行细节：在该方法前后添加时间戳日志，同时记录检查的文件路径类型（本地文件/网络存储）和耗时。如果是网络共享文件，可能导致进程阻塞，后续DB连接时系统资源（如文件描述符）不足，触发连接失败。
• 对比其他API端点的连接时机：其他端点是否在请求初期就建立DB连接，而此端点延迟到file_exists()之后？延迟连接可能刚好落在MySQL的资源波动窗口（如连接数突增、GC回收）。

2. 验证MySQL连接与服务器配置 #

• 检查PDO连接参数：确认dbsp.php中PDO->__construct的第四个参数数组，是否包含connect_timeout、mysql_connect_timeout（建议设为5-10秒），且该端点的参数与其他端点一致。
• 查看MySQL服务器日志：在错误发生的时间点（09-Jul-2023 14:56:50）搜索2006、max_connections、back_log相关日志，确认当时是否存在连接数打满、连接队列溢出的情况。同时核对wait_timeout、interactive_timeout配置，排除异常超时配置的影响。

3. 排查网络链路问题 #

• 确认该API所在服务器与MySQL的网络路径：是否和其他API端点走不同的负载均衡、防火墙或代理？用mtr持续监控该服务器到MySQL的网络链路，查看是否有间歇性丢包、延迟突增。
• 检查TCP连接状态：在错误高发时段用tcpdump捕获该服务器到MySQL的SYN包，确认是否存在SYN包被丢弃的情况（MySQLback_log满时会发生）。

4. 检查代码层面的隐蔽异常 #

• 监控file_exists()后的PHP全局状态：在调用setDownloaded()前，记录ini_get('open_basedir')、ini_get('max_execution_time')、getrusage()的输出，确认是否该操作修改了影响DB连接的配置或耗尽了资源。
• 排查DB抽象层的连接逻辑：检查dbsp.php的connect()方法是否存在连接池、单例缓存的异常处理，是否该端点的请求命中了某个未被正确清理的失效连接缓存（尽管堆栈显示是新建连接，但需排除逻辑漏洞）。

5. 定向压力测试复现场景 #

• 针对v2/download-file.php做万级请求压力测试：模拟真实请求中的file_exists()检查（使用相同的文件路径），同时监控MySQL的Threads_connected、Threads_running指标，以及服务器的CPU、内存、文件描述符使用情况，尝试复现错误。
• 关联错误发生时的系统事件：查看错误时间点的系统日志（如/var/log/syslog），确认是否存在服务器内存回收、磁盘IO突增、防火墙规则变更等操作。

内容的提问来源于stack exchange，提问作者Simon - ShortPixel