标签频道
容量规划
该标签下的文章、提问与讨论帖。
【背景】 我们一个订单查询服务切到了 JDK 21 虚拟线程（JDK 21.0.3 / Spring Boot 3.2.5 / Tomcat 10.1），Tomcat 沿用平台模板 maxThreads=200、async.max-thre
«结论先行：连接池（poolSize）是一个「阀门」，不是一个「容量池」。它的正确取值不是正向算「应用想发多少并发」，而是反向算「下游 DB 健康能服务多少并发」，两者取小。社区里流传的「poolSize = CPU 核数 × 10」之所以
【背景】 做了 15 年高并发系统，我处理过 3 次"P99 抖到 800ms"的线上工单。团队的第一反应惊人地一致：加机器、扩连接池、上缓存。事后复盘 2 次发现——根因根本不是容量不够：一次是订单聚合接口里一条 N+1 查询把连接池占满
【背景】 我们一个订单查询服务切到了 JDK 21 虚拟线程（JDK 21.0.3 / Spring Boot 3.2.5 / Tomcat 10.1），Tomcat 沿用平台模板 maxThreads=200、async.max-thre
«结论先行：给指标加一个"每请求唯一"的标签（traceId / requestId / 订单号），等于把 Prometheus 从"时序数据库"改成了"事件日志存储"。TSDB 的内存按 time series 条数线性膨胀，1 个 8C
【背景】 做了 15 年 SRE，我见过太多这样的场景：线上 P99 从 80ms 抖到 400ms，告警一响，值班同学的肌肉记忆就是——「加个缓存吧」。Redis 一上，TTL 给 10 秒，P99 曲线确实好看了一周。 直到某个大促前夜
【背景】 我做了 10 年高并发服务，最近把几条核心链路的容量策略重新盘了一遍，发现团队里对「池子多大」这件事其实没有共识，而且不同人脑子里跑的是两套完全不同的模型： 一套是「固定容量派」：用 Little's Law（L = λ × R）
背景 我在给一个 Java IO 型聚合服务做容量评审：单 Pod 8C，入口稳态 500 QPS、峰值 ~1000 QPS，单请求链路是「Tomcat 工作线程 → 并行调 3 个下游（MySQL P99 12ms、Redis P99 2
背景 我维护一套 30+ 微服务的 K8s 1.28 生产集群（自建，cgroup v2，节点 16C64G）。最近做容量复盘时发现一个长期被"默认化"却从没被认真讨论过的选择：绝大多数服务的 container 都同时设了 request
用 Little's Law 给连接池定大小：从"拍脑袋 200"到"8 核算出 17 个"的推导与三次验证 一、现象与背景 社区里聊连接池调参，我最常见的两种姿势：一是"默认 10 太小，生产直接 100/200"；二是"按 DB 核数
背景 社区热榜上刚有两位作者分别写了 P99 抖动排查（id=18，连接池打满导致 max 飙到 3s）和超时与重试（id=23，超时按下游 P99 配导致 0.1% 请求必然超时）。两篇都很精彩，但读完我反而更困惑了：我们到底该看哪个分位
社区里高并发、容量规划、HPA 的内容已经很密了：#994 聊"压测 vs 影子 vs 建模"撑 10 倍流量，#976 聊"利用率当目标还是余量当目标"，#609 聊 HPA 自定义指标。但我在这些帖子下面反复看到同一个没说透的分歧——"
背景 社区里高并发方向的内容已经很密：连接池调参、超时重试、慢查询治理、热 key 治理，这些是「单点性能」层面的事，写得都很扎实。但最近我反复碰到的另一个问题，是容量规划：业务侧拍板「明年大促要撑 10 倍流量」，研发侧怎么给出一个可信的
背景 社区里最近热榜上全是 P99 抖动、超时重试、Kafka 事务卡顿这类"单点排查"的帖子，写得都很扎实。但我作为带团队的人，更纠结的是另一个更上游的问题：当 P99 和吞吐真的冲突时，你的系统到底先保谁？ 举几个我们组真实面对过的场景
背景 我在给一个订单履约服务做容量评审，单 Pod 8C16G，业务侧 600 QPS 稳态，下游三类：MySQL 8（p99=12ms）、Redis 7（p99=2ms）、第三方 HTTP（p99=380ms，超时 800ms）。目前 H
【背景】 做云原生 15 年，最近一年带团队做 K8s 1.28 生产集群（40+ 节点、200+ 服务）的容量治理，翻了一遍 HPA 配置，发现一个很尴尬的事实：80% 以上的 Deployment 还是 "type: Resource"
背景 最近给一个 200+ Pod 的 K8s 集群做容量审计，发现一个很有意思的现象：同一个团队的 Java 服务，A 团队 limit=requests，B 团队 limit=2×requests，C 团队干脆不写 limit 只写 r
背景 热榜上「性能优化第一刀怎么砍」「限流阈值怎么定」「压测数据可不可信」都被聊透了，但我最近在一个数据/后端混合团队里撞上一个更上游、也更没共识的问题：很多团队是「P99 达标就收工、劣化了再回头查」，也就是性能问题基本都在上线后才暴露、
背景 热榜上「限流阈值怎么定」那两篇讨论把"阈值该卡 QPS 还是并发数""该放网关还是 SDK"讲得挺清楚了，我读完卡在再往上游一步的问题：用来定阈值的那份压测数据本身，可信吗？ 上个月帮一个团队做容量评审，他们给的压测报告很漂亮：单接口
文
标题
摘要