Hermes Agent 数据库连接池调优实录从连接耗尽到参数落地的完整排查过程【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent上周三凌晨一台跑着 Hermes Agent 网关的 VPS 开始出现怪事用户消息进来后界面卡在处理中不动偶尔直接报数据库锁定错误重启服务后又恢复正常。连续三次都在流量高峰时段复现。顺着日志摸下去根子出在数据库连接池上——SQLite 连接没被及时释放新请求只能干等上一把锁高峰一来就排队。这篇实录记录整个定位与调参过程按先看什么信号、再动哪个参数、最后怎么确认的顺序走一遍看完你就能在自己的 Hermes Agent 部署里把同类问题压下去。症状定位怎么判断问题真的出在连接池连接池简单说就是复用数据库连接的一批常驻通道省去每次重新建连的开销出问题时不会直接告诉你我满了而是要靠几个可观测信号交叉验证日志特征反复出现database is locked、busy timeout expired、cannot acquire connection之类的报错且集中在特定时段。Hermes Agent 的状态读写集中在 agent/verification_evidence.py 这类模块它们的连接生命周期值得优先检查。等待时间拉长同一批会话接口从秒回变成几秒起步但 CPU、内存都不高——算力没瓶颈就是请求在门口排队。重启即愈重启服务后立刻正常说明不是数据损坏而是连接/锁随运行时间逐渐堆积。三个信号里命中两个以上基本可以把嫌疑锁定到连接池与连接回收机制。调参实操先调哪个再调哪个⚠️ 调参顺序很重要先保证连接一定被关再调等多久最后才是开多少条。反过来调放大了泄漏也放大了故障。参数名建议区间作用大白话连接关闭代码层面必做每次用完立即close()而不是留给垃圾回收器这是所有调参的前提busy_timeout忙等超时3000–5000 ms数据库被锁时当前操作最多等多久才报错等不够就误伤正常请求WAL 模式journal_mode开启带回退读写不再互相挡路并发提升最明显的一档并发连接数按需通常个位数Hermes Agent 以本机 SQLite 为主连接不是越多越好够用即可长事务时长控制到秒级事务拖得越久占着锁的时间越长别人的等待就线性变差最小可用的连接写法可以参考仓库里的实际实现连接 WAL 兜底 忙等超时且退出时强制关闭conn sqlite3.connect(db_path) conn.execute(PRAGMA journal_modeWAL) # 失败时有回退逻辑 conn.execute(PRAGMA busy_timeout5000) try: with conn: ... finally: conn.close() # 关键with 只管提交/回滚不会关连接验证与回滚调整后看什么指标确认生效改完不要直接宣布胜利观察一个完整的高峰周期至少覆盖一次你平时最忙的时段锁定错误计数归零database is locked与超时类报错不再出现这是最硬的指标排队时间回落高峰时段接口响应时间回到调整前的基线水平无新泄漏运行数小时后进程打开的文件描述符数、磁盘上-wal/-shm文件体积不再持续增长。什么情况下退回上一版配置如果调大busy_timeout后响应整体变慢大家多等了 5 秒还没等到锁或者 WAL 开启后日志里出现频繁的模式回退告警说明方向不对先回滚再换思路。每次只动一个参数回滚才有意义。避坑速查四条高频坑坑只加超时不关连接→ 对策超时只是止血代码里必须有显式close()泄漏不除一切白搭。坑把 SQLite 当成 MySQL 去堆连接数→ 对策本机库瓶颈在锁不在连接数优先上 WAL、缩短事务而不是无限加通道。坑只测空闲环境就上线→ 对策务必用你真实的高峰流量或压测脚本模拟并发写入复测空闲环境测不出锁竞争。坑多个进程/线程共享同一个库文件却没约定超时→ 对策每个打开连接的地方都设busy_timeout别让谁等谁变成随机行为。排查走到这里思路其实就三件事先确认连接有被关掉再给等待设一个合理的上限最后用高峰数据说话。参数只是手段连接生命周期管理才是本体。更多状态层与存储相关的实现细节可以顺着 agent/ 目录下的源码往下看对照官方文档的连接与状态说明基本能覆盖绝大多数部署场景。【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
尧图网络