线上卡顿问题总结 2026 年 9 月 30 日，线上页面出现间歇性加载缓慢、偶尔无法加载的情况。浏览器记录显示，带登录信息的 /api/me 请求等待约 30 秒后返回 500，随后聊天权限、智能体和项目文件列表也无法正常加载。排查时服务器 CPU 负载很低、内存充足，前后端健康接口响应很快；但健康接口不查询数据库，因此不能说明业务请求正常。未登录的 /api/me 也能迅速返回 401，表明请求可以经过前端转发到后端。 随后，线上日志给出了明确原因：QueuePool limit of size 5 overflow 10 reached, connection timed out, timeout 30.00。这表示后端数据库连接池当时已被占满，新请求等待 30 秒仍拿不到连接，最终报错。确认的是连接池耗尽，尚未确认连接为何被长期占用。 可能原因包括短时间并发请求增多、慢查询、聊天流式生成期间持有数据库连接，或连接未及时释放；低 CPU 负载不排除这些等待问题。稍后的快照显示 MySQL 仅有 4 个连接，说明当时已恢复，但由于尚未核对后端 PID，不能判断是连接自行释放还是服务重启后的结果。未关闭的 journalctl -f 和此前只在本地完成的文件读取修改，没有证据表明是此次线上故障的原因。 为避免复发，应优先排查请求持有数据库 Session 的时间，尤其是聊天流式请求等待模型返回期间是否仍占用连接，并确保异常或取消请求时连接被释放。同时记录连接池的占用数、等待时间和超时次数，在并发聊天与页面加载场景下做压力验证。可以按实际负载调整连接池容量，但单纯调大连接池不能替代查清连接被占用的原因。下次发生时，应先保存后端日志、进程 PID 和数据库连接快照；重启后端只能作为恢复服务的临时措施。