本文是《MCP实战手记系列十MCP Server高可用实战》的延伸知识点。多实例、负载均衡、熔断、降级都配完之后还有两件事没解决系统现在到底什么状态以及那些池子到底设多大。前者决定能不能及时发现问题后者决定能不能扛住。一、至少要看这6个指标指标为什么各实例QPS / 错误率 / P99平均值会骗人一定看分位数健康实例数Nginx认为还活着几个少了要立刻知道熔断状态哪些下游的熔断器是打开的、开了多久降级次数三个级别各触发了多少次能反映下游健康度线程池 / 连接池使用率快满的时候系统已经在排队了只是还没报错依赖可用性DB、Redis、下游接口各自的可用状态告警阈值我用的经验值错误率5%、P991s、实例不健康、熔断打开超过30秒、线程池使用率80%这条算预警不是告警。有两个指标容易被漏掉降级次数和熔断持续时间。降级是系统设计好的兜底正因为它不报错所以没人管——但降级次数持续走高说明下游一直在出问题只是被兜住了而已。熔断打开超过30秒也一样那意味着下游已经病了半分钟。另外熔断这块有个原则值得单独说fallback必须极简不能再依赖外部服务。下游挂了、fallback也跟着挂那就真没有退路了。降级是为了收窄影响面不是换个地方继续失败。二、池子设多大**线程池不是越大越好。**线程多了上下文切换开销跟着涨反而变慢。粗分CPU密集型≈核心数1IO密集型≈核心数×2~10。MCP Server偏IO密集调下游、查库但也别往大了拍。数据库连接池有公式连接数 ≈ 核心数 × (1 等待时间/计算时间)通常10~20个就够。这里有个反直觉的点——连接开太多会让数据库端锁竞争加剧吞吐反而下降。很多时候连接池不够用的真正原因是查询太慢不是池子太小。HTTP连接池看峰值并发和长连接复用率而且每个下游要独立算不能共用一个全局数。**最重要的一条拍脑袋定的数基本都不准。**上线后看实际使用率再调——长期低于30%说明设大了白占资源经常打满说明设小了。这也是上面那6个指标非要留着的原因它们不只是用来告警的也是调参的依据。三、为什么不一次配到位因为容量跟流量模式强相关。我在系列十里做过一组对照同样是12个并发打一个8连接的池查询在200ms级时12个请求全部正常返回一个都没排队把查询退化到4秒立刻有4个请求拿不到连接。同样的池子只是查询耗时变了结果完全不同。所以池子容量不是一个静态数字它是并发 × 单次耗时的函数。按今天的耗时配的容量明天下游慢一倍就不够用了。小结先看6个指标再按使用率调池子且要意识到容量会随下游耗时漂移。配完高可用就不管了等于盲飞。同专题推荐本文是「MCP Server高可用」小专题的第4篇共5篇Nginx开源版没有主动探活四种补救方案和一个能用的脚本发版就掉请求Spring Boot优雅停机的四步超时不是一个数字是一套体系MCP Server的五条约束高可用配完之后该看哪几个指标池子该设多大← 当前这篇缓存穿透、击穿、雪崩三个概念三种解法链接待补相关阅读《MCP实战手记系列十MCP Server高可用实战》本文延伸自该篇含连接池对照实验的原始输出《MCP实战手记系列九生产化MCP Server的6层安全防护》配套代码https://gitee.com/ethanliang2016/mcp-in-actiontagv10