Hermes Agent连接池参数怎么配4 个指标验证调优生效凌晨 3 点告警连接池打满接口 P99 飙到 8 秒日志刷满PoolTimeout。别急着拉大数字——Hermes Agent 的出站连接池和会话状态库是两处独立配置这份指南直接给你能跑的参数和验证命令。 一份能直接跑的配置长什么样连接池预先开好一批连接反复用省掉每次请求的握手开销在 Hermes Agent 里分两块出站 HTTP 池和 SQLite 会话库。下面这份配置摘录里outbound段的值对应 agent/process_bootstrap.py 中httpx.Limits/httpx.Timeout的默认常量state段对应 acp_adapter/session.py 初始化state.db的参数。outbound: # LLM 提供商请求的出站连接池 pool: max_keepalive_connections: 20 # 空闲连接复用上限多出来的空闲连接直接关闭 max_connections: 100 # 并发出站连接硬上限超过的新请求排队等待 keepalive_expiry: 20.0 # 空闲连接回收秒数必须小于反向代理的 30-60s 超时 timeout: connect: 15.0 # TCP 建连超时秒超时说明是网络层问题 read: null # SSE 流式场景不设读超时别动 write: 15.0 pool: 10.0 # 从池里取连接的最长等待秒超时即 PoolTimeout state: # 会话状态存储SQLite db: path: state.db # 位于 Hermes 主目录下的状态库 journal_mode: wal # 切到 WAL预写日志允许并发读写并发必备 busy_timeout: 5000 # 锁等待毫秒数防并发写时 database is locked monitoring: export: otlp: endpoint: http://collector:4318/v1/traces # OTLP 上报地址验证指标全靠它 headers_env: Authorization: HERMES_OTLP_TOKEN # 取值放环境变量配置里不写明文⚠️ 别一上来把max_connections拉到 200提供商侧的并发配额通常先扛不住池子调大只会让 429 来得更快。 不同规模下参数怎么选数据库连接数计算没有标准公式核心只有一件事你的并发出站请求有多少每条连接平均占多久。三档推荐值如下参数单机开发中小生产高并发集群max_keepalive_connections52050max_connections20100300keepalive_expiry秒202020timeout.pool秒51010SQLite busy_timeout毫秒200050005000 只读副本单机开发就你一个用户加几个会话并发上限天然低给 20 够用不够用时问题立刻暴露调优反而没意义。中小生产100 是代码默认值来源是LLM 主调用并发 压缩、标题生成等后台任务的叠加keep-alive 20 约为它的五分之一贴合常规 QPS。高并发集群按节点数线性放大前先查提供商限流并发数 / RPMDockerfile 里甚至写死了 SQLite 版本校验因为集群规模下先崩的往往是 SQLite 而不是出站池。keepalive_expiry 三档都锁死 20这个值由反向代理的空闲超时30-60 秒约束和你的规模无关。调大了连接还没复用到就先被服务端掐断。✅ 改完配置怎么确认真的生效改配置 ≠ 生效。出站参数目前硬编码在源码里改完必须重启进程OTLP 上报结构见 agent/monitoring/otlp_exporter.pyOTLP 即 OpenTelemetry 上报协议span 指标经它进你的 Collector 可查endpoint不配下面一半指标看不见。# 1) 确认源码常量已改且进程重启预期输出新值 100 grep -n max_connections agent/process_bootstrap.py # 2) WAL 是否真的生效预期输出 wal sqlite3 state.db PRAGMA journal_mode; # 3) 两类错误计数调优后都应降到 0 grep -c PoolTimeout logs/gateway.log grep -c database is locked logs/gateway.log指标验证什么在哪看PoolTimeout 次数池耗尽是否解决上面命令 3或日志面板出站请求 P99延迟是否真降Grafana 查httpxspan 的 duration p99对比改动前后WAL 模式state.db 配置生效命令 2 输出waldatabase is locked 次数并发写压力命令 3gateway_health span 速率监控管道活着Collector 面板查该 span 每秒计数应稳定前两项下降、后两项归零闭环完成。若 WAL 输出不是wal先跑python -c import sqlite3; print(sqlite3.sqlite_version)——低于 3.51.3 的版本有 WAL-reset 上游 bug。⚠️ 翻车场景速查连接池超时设置和 SQLite 的坑大多重复出现按现象对号入座现象根因修复动作高峰后 10 秒起间歇PoolTimeoutmax_connections 偏小或流式连接长时间不释放先查提供商并发配额再上调到 150仍耗尽则排查长占用连接空闲后首请求报peer closed connectionkeepalive_expiry 大于代理空闲超时复用了已被服务端关闭的连接keepalive_expiry 降到 20 秒贴着代理 30 秒上限并发写报database is locked还是默认回滚日志模式读写互相阻塞设journal_mode: walbusy_timeout: 5000全部请求挂起但无报错timeout.pool 太大把池耗尽掩盖成慢降到 5-10 秒快速失败再查谁在占连接部署后 state.db 异常、CPU 偏高旧版 SQLite 的 WAL-reset bug升级 SQLite ≥ 3.51.3Dockerfile 已内置该校验代码里对这些 sqlite 异常的处理路径可看 agent/insights.py排查日志时优先搜OperationalError关键字。一句话收束出站并发设上限、在代理超时前回收空闲连接、池满时快速失败。默认值看 agent/process_bootstrap.py效果盯上面 4 个指标。创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Hermes Agent连接池参数怎么配4 个指标验证调优生效凌晨 3 点告警连接池打满接口 P99 飙到 8 秒日志刷满PoolTimeout。别急着拉大数字——Hermes Agent 的出站连接池和会话状态库是两处独立配置这份指南直接给你能跑的参数和验证命令。 一份能直接跑的配置长什么样连接池预先开好一批连接反复用省掉每次请求的握手开销在 Hermes Agent 里分两块出站 HTTP 池和 SQLite 会话库。下面这份配置摘录里outbound段的值对应 agent/process_bootstrap.py 中httpx.Limits/httpx.Timeout的默认常量state段对应 acp_adapter/session.py 初始化state.db的参数。outbound: # LLM 提供商请求的出站连接池 pool: max_keepalive_connections: 20 # 空闲连接复用上限多出来的空闲连接直接关闭 max_connections: 100 # 并发出站连接硬上限超过的新请求排队等待 keepalive_expiry: 20.0 # 空闲连接回收秒数必须小于反向代理的 30-60s 超时 timeout: connect: 15.0 # TCP 建连超时秒超时说明是网络层问题 read: null # SSE 流式场景不设读超时别动 write: 15.0 pool: 10.0 # 从池里取连接的最长等待秒超时即 PoolTimeout state: # 会话状态存储SQLite db: path: state.db # 位于 Hermes 主目录下的状态库 journal_mode: wal # 切到 WAL预写日志允许并发读写并发必备 busy_timeout: 5000 # 锁等待毫秒数防并发写时 database is locked monitoring: export: otlp: endpoint: http://collector:4318/v1/traces # OTLP 上报地址验证指标全靠它 headers_env: Authorization: HERMES_OTLP_TOKEN # 取值放环境变量配置里不写明文⚠️ 别一上来把max_connections拉到 200提供商侧的并发配额通常先扛不住池子调大只会让 429 来得更快。 不同规模下参数怎么选数据库连接数计算没有标准公式核心只有一件事你的并发出站请求有多少每条连接平均占多久。三档推荐值如下参数单机开发中小生产高并发集群max_keepalive_connections52050max_connections20100300keepalive_expiry秒202020timeout.pool秒51010SQLite busy_timeout毫秒200050005000 只读副本单机开发就你一个用户加几个会话并发上限天然低给 20 够用不够用时问题立刻暴露调优反而没意义。中小生产100 是代码默认值来源是LLM 主调用并发 压缩、标题生成等后台任务的叠加keep-alive 20 约为它的五分之一贴合常规 QPS。高并发集群按节点数线性放大前先查提供商限流并发数 / RPMDockerfile 里甚至写死了 SQLite 版本校验因为集群规模下先崩的往往是 SQLite 而不是出站池。keepalive_expiry 三档都锁死 20这个值由反向代理的空闲超时30-60 秒约束和你的规模无关。调大了连接还没复用到就先被服务端掐断。✅ 改完配置怎么确认真的生效改配置 ≠ 生效。出站参数目前硬编码在源码里改完必须重启进程OTLP 上报结构见 agent/monitoring/otlp_exporter.pyOTLP 即 OpenTelemetry 上报协议span 指标经它进你的 Collector 可查endpoint不配下面一半指标看不见。# 1) 确认源码常量已改且进程重启预期输出新值 100 grep -n max_connections agent/process_bootstrap.py # 2) WAL 是否真的生效预期输出 wal sqlite3 state.db PRAGMA journal_mode; # 3) 两类错误计数调优后都应降到 0 grep -c PoolTimeout logs/gateway.log grep -c database is locked logs/gateway.log指标验证什么在哪看PoolTimeout 次数池耗尽是否解决上面命令 3或日志面板出站请求 P99延迟是否真降Grafana 查httpxspan 的 duration p99对比改动前后WAL 模式state.db 配置生效命令 2 输出waldatabase is locked 次数并发写压力命令 3gateway_health span 速率监控管道活着Collector 面板查该 span 每秒计数应稳定前两项下降、后两项归零闭环完成。若 WAL 输出不是wal先跑python -c import sqlite3; print(sqlite3.sqlite_version)——低于 3.51.3 的版本有 WAL-reset 上游 bug。⚠️ 翻车场景速查连接池超时设置和 SQLite 的坑大多重复出现按现象对号入座现象根因修复动作高峰后 10 秒起间歇PoolTimeoutmax_connections 偏小或流式连接长时间不释放先查提供商并发配额再上调到 150仍耗尽则排查长占用连接空闲后首请求报peer closed connectionkeepalive_expiry 大于代理空闲超时复用了已被服务端关闭的连接keepalive_expiry 降到 20 秒贴着代理 30 秒上限并发写报database is locked还是默认回滚日志模式读写互相阻塞设journal_mode: walbusy_timeout: 5000全部请求挂起但无报错timeout.pool 太大把池耗尽掩盖成慢降到 5-10 秒快速失败再查谁在占连接部署后 state.db 异常、CPU 偏高旧版 SQLite 的 WAL-reset bug升级 SQLite ≥ 3.51.3Dockerfile 已内置该校验代码里对这些 sqlite 异常的处理路径可看 agent/insights.py排查日志时优先搜OperationalError关键字。一句话收束出站并发设上限、在代理超时前回收空闲连接、池满时快速失败。默认值看 agent/process_bootstrap.py效果盯上面 4 个指标。创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
