Hindsight 性能调优实战recall、retain 与连接池的延迟瓶颈定位【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight早上的 recall p95 告警响了一条记忆查询从 300ms 变成 1.5s本地 Ollama 部署的 retain 队列积压了几个小时。这篇文章处理的就是这类 Hindsight 性能调优的完整过程——给出现象、用项目自带的指标和 trace 定位瓶颈、调参、再验证效果。Hindsight 的默认值是针对云 LLM 和多核服务器调的一旦你换成本地模型、多 bank 或者读写比例变化默认值就不再是最优解了。如果监控还没搭起来先用scripts/dev/start-monitoring.sh拉起 Grafana LGTM 本地栈导入 monitoring/grafana/dashboards/ 里现成的三块面板Operations、LLM Metrics、API Service后文所有定位手段都依赖它们。recall 变慢重排序器是第一嫌疑人现象recall 接口要跑 1~2 秒Hindsight 进程 CPU 打得很高但向量检索本身在 10 万条 fact 规模下通常只要 10~50ms。慢的几乎总是 rerank 这一步——默认每次 recall 最多把 300 个候选送进 cross-encoder。定位两个入口一是在 recall 请求里传trace: true返回里会有rerank_prefilter阶段保留了/丢弃了多少候选二是开 OTELHINDSIGHT_API_OTEL_TRACES_ENABLEDtruespan 树里hindsight.recall_rerank的时间占比一目了然。指标侧直接算 p95histogram_quantile(0.95, rate(hindsight_operation_duration_bucket{operationrecall}[5m]))调整# 默认 300 个候选进 cross-encoder降到 100工作量按比例下降 export HINDSIGHT_API_RERANKER_MAX_CANDIDATES100 # FP16 按长度分桶批处理质量不变CPU/MPS 上有 30% 以上的提速 export HINDSIGHT_API_RERANKER_LOCAL_FP16true export HINDSIGHT_API_RERANKER_LOCAL_BUCKET_BATCHINGtrue纯 CPU 机器扛不住 cross-encoder 时把HINDSIGHT_API_RERANKER_PROVIDER换成更轻量的flashrank。另外别对所有查询都上highbudget——日常问答用low/mid把高开销留给需要全面分析的问题。验证对比调整前后的同一条 PromQLhindsight_operation_duration_bucket{operationrecall}的 p95 应明显回落再开一次trace: true确认 rerank 阶段耗时占比降下来了。本地 LLM 被 Hindsight 拖垮retain 超时、邻居服务变慢现象把 LLM 从云端切到 Ollama、llama.cpp 或 vLLM 之后retain 开始返回超时 500同时共享同一端点的主 agent 推理也变慢了。原因不复杂HINDSIGHT_API_LLM_MAX_CONCURRENT默认是 32假设的是能吞几十个并发请求的云厂商本地服务器只有几个 slot全被 Hindsight 填满后谁都别想跑。定位histogram_quantile(0.95, rate(hindsight_llm_duration_bucket{successtrue}[5m]))按scope标签拆开看memory对应 retain 的事实抽取consolidation对应记忆合并。如果scopememory的 p95 高且successfalse的调用不少就是 LLM 吞吐不够、排队超时而不是 Hindsight 自身的问题。调整# 默认 32 假设云厂商本地 server 只有几个 slot留 2 个给 retain/consolidation 并发 export HINDSIGHT_API_LLM_MAX_CONCURRENT2 # 分操作限流后台任务不挤占在线读取 export HINDSIGHT_API_RETAIN_LLM_MAX_CONCURRENT1 export HINDSIGHT_API_CONSOLIDATION_LLM_MAX_CONCURRENT1# 小模型出 token 慢启动后首次请求还要付模型加载时间 export HINDSIGHT_API_LLM_TIMEOUT300 export HINDSIGHT_API_LLM_MAX_RETRIES2 # 本地端点没有限流重试大多是白等 export HINDSIGHT_API_LLM_REASONING_EFFORTlow # 抽取类任务不需要深度推理consolidation 默认一次把 8 条 fact 塞进一个 LLM 调用小上下文窗口的小模型容易被超大 prompt 拖出错误响应export HINDSIGHT_API_CONSOLIDATION_LLM_BATCH_SIZE2 # 默认 8调小更稳验证在 LLM Metrics 面板确认hindsight_llm_calls_total的失败率回落到零hindsight_llm_duration_bucket的 p95 下降顺带观察主 agent 在共享端点上的响应时间是否恢复正常——这是判断 slot 争抢是否解决的直接证据。retain 队列积压worker 槽位与数据库连接池现象异步批量 retain 提交后父 operation 长时间停在 pending队列不消化。另一个信号是curl localhost:8888/health/ready返回里db_pool_waiting持续大于 0——有请求在排队等数据库连接。定位/health/ready的db_acquire_ms和db_pool_waiting能区分两种病池子耗尽排队拿连接还是数据库本身慢拿到了连接但查询慢。池子利用率用现成的 gauge 算hindsight_db_pool_size / hindsight_db_pool_max # 持续接近 1 说明池子太小worker 侧看hindsight_operation_total{sourceworker}的吞吐失败用hindsight_async_operations{statusfailed}查——它反映的是重试耗尽后的真实失败比 worker 的 success 标签更权威。调整# worker 并发任务上限默认 10积压严重时调大 export HINDSIGHT_API_WORKER_MAX_SLOTS20 # 连接池上限默认 100利用率长期贴近上限时再上调 export HINDSIGHT_API_DB_POOL_MAX_SIZE200 # 读请求走只读副本把主库留给写入 export HINDSIGHT_API_READ_DATABASE_URLpostgres://readonly-replica...# 配合 async retain事实抽取走 provider 的 Batch APILLM 成本约降一半 export HINDSIGHT_API_RETAIN_BATCH_ENABLEDtrue单 bank 和多 bank 的压力不一样多 bank 下每个 bank 有独立的数据和索引bank 数量上来的时候连接池和 worker 槽位的余量要重新核算。验证db_pool_waiting回落到 0hindsight_operation_duration按sourceworker过滤的 p95 下降父 operation 的完成时间回到预期内。配置速查表规模关键配置注意事项小规模笔记本/单机 本地 LLMLLM_MAX_CONCURRENT2、LLM_TIMEOUT300、LLM_REASONING_EFFORTlow、RERANKER_MAX_CANDIDATES100共享端点要为其他客户端留 slotCPU 机器可换flashrank中等云 LLM数百用户保持默认并发READ_DATABASE_URL读写分离RETAIN_BATCH_ENABLEDtruerecall 按查询复杂度选low/midbudget别默认high大规模1000 用户多 bankAPI 多实例 共享 PostgreSQLWORKER_MAX_SLOTS与DB_POOL_MAX_SIZE联动调大导入 monitoring/grafana/dashboards/ 三块面板对 recall p95 和池子利用率设告警调参的顺序建议从本文的排查路径出发先确认瓶颈落在 rerank、LLM 还是连接池再动对应的那组变量一次只改一类用/metrics的前后对比说话。完整的默认值清单在 hindsight-api-slim/hindsight_api/config.py各操作的延迟特征与官方推荐写法见 hindsight-docs/docs/developer/performance.md 和 hindsight-docs/docs/developer/monitoring.md。【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Hindsight 性能调优实战：recall、retain 与连接池的延迟瓶颈定位
Hindsight 性能调优实战recall、retain 与连接池的延迟瓶颈定位【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight早上的 recall p95 告警响了一条记忆查询从 300ms 变成 1.5s本地 Ollama 部署的 retain 队列积压了几个小时。这篇文章处理的就是这类 Hindsight 性能调优的完整过程——给出现象、用项目自带的指标和 trace 定位瓶颈、调参、再验证效果。Hindsight 的默认值是针对云 LLM 和多核服务器调的一旦你换成本地模型、多 bank 或者读写比例变化默认值就不再是最优解了。如果监控还没搭起来先用scripts/dev/start-monitoring.sh拉起 Grafana LGTM 本地栈导入 monitoring/grafana/dashboards/ 里现成的三块面板Operations、LLM Metrics、API Service后文所有定位手段都依赖它们。recall 变慢重排序器是第一嫌疑人现象recall 接口要跑 1~2 秒Hindsight 进程 CPU 打得很高但向量检索本身在 10 万条 fact 规模下通常只要 10~50ms。慢的几乎总是 rerank 这一步——默认每次 recall 最多把 300 个候选送进 cross-encoder。定位两个入口一是在 recall 请求里传trace: true返回里会有rerank_prefilter阶段保留了/丢弃了多少候选二是开 OTELHINDSIGHT_API_OTEL_TRACES_ENABLEDtruespan 树里hindsight.recall_rerank的时间占比一目了然。指标侧直接算 p95histogram_quantile(0.95, rate(hindsight_operation_duration_bucket{operationrecall}[5m]))调整# 默认 300 个候选进 cross-encoder降到 100工作量按比例下降 export HINDSIGHT_API_RERANKER_MAX_CANDIDATES100 # FP16 按长度分桶批处理质量不变CPU/MPS 上有 30% 以上的提速 export HINDSIGHT_API_RERANKER_LOCAL_FP16true export HINDSIGHT_API_RERANKER_LOCAL_BUCKET_BATCHINGtrue纯 CPU 机器扛不住 cross-encoder 时把HINDSIGHT_API_RERANKER_PROVIDER换成更轻量的flashrank。另外别对所有查询都上highbudget——日常问答用low/mid把高开销留给需要全面分析的问题。验证对比调整前后的同一条 PromQLhindsight_operation_duration_bucket{operationrecall}的 p95 应明显回落再开一次trace: true确认 rerank 阶段耗时占比降下来了。本地 LLM 被 Hindsight 拖垮retain 超时、邻居服务变慢现象把 LLM 从云端切到 Ollama、llama.cpp 或 vLLM 之后retain 开始返回超时 500同时共享同一端点的主 agent 推理也变慢了。原因不复杂HINDSIGHT_API_LLM_MAX_CONCURRENT默认是 32假设的是能吞几十个并发请求的云厂商本地服务器只有几个 slot全被 Hindsight 填满后谁都别想跑。定位histogram_quantile(0.95, rate(hindsight_llm_duration_bucket{successtrue}[5m]))按scope标签拆开看memory对应 retain 的事实抽取consolidation对应记忆合并。如果scopememory的 p95 高且successfalse的调用不少就是 LLM 吞吐不够、排队超时而不是 Hindsight 自身的问题。调整# 默认 32 假设云厂商本地 server 只有几个 slot留 2 个给 retain/consolidation 并发 export HINDSIGHT_API_LLM_MAX_CONCURRENT2 # 分操作限流后台任务不挤占在线读取 export HINDSIGHT_API_RETAIN_LLM_MAX_CONCURRENT1 export HINDSIGHT_API_CONSOLIDATION_LLM_MAX_CONCURRENT1# 小模型出 token 慢启动后首次请求还要付模型加载时间 export HINDSIGHT_API_LLM_TIMEOUT300 export HINDSIGHT_API_LLM_MAX_RETRIES2 # 本地端点没有限流重试大多是白等 export HINDSIGHT_API_LLM_REASONING_EFFORTlow # 抽取类任务不需要深度推理consolidation 默认一次把 8 条 fact 塞进一个 LLM 调用小上下文窗口的小模型容易被超大 prompt 拖出错误响应export HINDSIGHT_API_CONSOLIDATION_LLM_BATCH_SIZE2 # 默认 8调小更稳验证在 LLM Metrics 面板确认hindsight_llm_calls_total的失败率回落到零hindsight_llm_duration_bucket的 p95 下降顺带观察主 agent 在共享端点上的响应时间是否恢复正常——这是判断 slot 争抢是否解决的直接证据。retain 队列积压worker 槽位与数据库连接池现象异步批量 retain 提交后父 operation 长时间停在 pending队列不消化。另一个信号是curl localhost:8888/health/ready返回里db_pool_waiting持续大于 0——有请求在排队等数据库连接。定位/health/ready的db_acquire_ms和db_pool_waiting能区分两种病池子耗尽排队拿连接还是数据库本身慢拿到了连接但查询慢。池子利用率用现成的 gauge 算hindsight_db_pool_size / hindsight_db_pool_max # 持续接近 1 说明池子太小worker 侧看hindsight_operation_total{sourceworker}的吞吐失败用hindsight_async_operations{statusfailed}查——它反映的是重试耗尽后的真实失败比 worker 的 success 标签更权威。调整# worker 并发任务上限默认 10积压严重时调大 export HINDSIGHT_API_WORKER_MAX_SLOTS20 # 连接池上限默认 100利用率长期贴近上限时再上调 export HINDSIGHT_API_DB_POOL_MAX_SIZE200 # 读请求走只读副本把主库留给写入 export HINDSIGHT_API_READ_DATABASE_URLpostgres://readonly-replica...# 配合 async retain事实抽取走 provider 的 Batch APILLM 成本约降一半 export HINDSIGHT_API_RETAIN_BATCH_ENABLEDtrue单 bank 和多 bank 的压力不一样多 bank 下每个 bank 有独立的数据和索引bank 数量上来的时候连接池和 worker 槽位的余量要重新核算。验证db_pool_waiting回落到 0hindsight_operation_duration按sourceworker过滤的 p95 下降父 operation 的完成时间回到预期内。配置速查表规模关键配置注意事项小规模笔记本/单机 本地 LLMLLM_MAX_CONCURRENT2、LLM_TIMEOUT300、LLM_REASONING_EFFORTlow、RERANKER_MAX_CANDIDATES100共享端点要为其他客户端留 slotCPU 机器可换flashrank中等云 LLM数百用户保持默认并发READ_DATABASE_URL读写分离RETAIN_BATCH_ENABLEDtruerecall 按查询复杂度选low/midbudget别默认high大规模1000 用户多 bankAPI 多实例 共享 PostgreSQLWORKER_MAX_SLOTS与DB_POOL_MAX_SIZE联动调大导入 monitoring/grafana/dashboards/ 三块面板对 recall p95 和池子利用率设告警调参的顺序建议从本文的排查路径出发先确认瓶颈落在 rerank、LLM 还是连接池再动对应的那组变量一次只改一类用/metrics的前后对比说话。完整的默认值清单在 hindsight-api-slim/hindsight_api/config.py各操作的延迟特征与官方推荐写法见 hindsight-docs/docs/developer/performance.md 和 hindsight-docs/docs/developer/monitoring.md。【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考