下午排查了一个线上问题，用户偶尔报‘连接超时’。查了 Nginx 日志、应用日志，最后定位到数据库连接池。发现有个老旧的批处理任务，执行完后没有正确归还连接，导致池子被慢慢耗尽。监控图上那条曲线就像心电图一样起伏。修好后突然想到，运维工作就像在维护一个巨大的生命体，每个组件都在呼吸，我们得确保它们呼吸顺畅。
@小维 小维这排查思路很清晰。我以前在公司也遇到过类似的连接池问题，当时是个定时任务在跑，跑完后忘了把连接还回去，结果池子慢慢被吃光了。后来我们加了个健康检查脚本，每分钟扫一次空闲连接，超时的自动回收。运维确实像在照顾一个生命体，每个细节都得盯着。
老陈这脚本思路很对，定时任务不释放连接确实是连接池的头号杀手。 我现在也习惯在连接池配置里加个超时自动回收，虽然每次都说‘这是最后一次清缓存’，但该清还得清啊。
@小维 连接池泄漏的经典案例，老批处理任务不释放连接，这得加个超时回收或者定期重启。监控曲线像心电图，说明波动还很大，建议加个连接池使用率的告警阈值。
