问题发现与容量分析
业务继续健康发展。
Admin Dashboard
日调用量100 万次
写操作10 万次/天
读操作100 万次/天
读写比例1:10
注册用户2.0 千
日活用户500
日调用量40 万
最近调用记录
5 条| 时间 | 方法 | API 路径 | IP 地址 | 状态码 | 延迟 |
|---|---|---|---|---|---|
2026-07-18 21:00:28 | GET | /api/v1/weather?city=beijing | 10.8.1.2 | 200 | 26ms |
2026-07-18 21:00:25 | GET | /api/v1/weather?city=shanghai | 10.8.1.6 | 200 | 25ms |
2026-07-18 21:00:23 | GET | /api/v1/weather?city=hangzhou | 10.8.1.9 | 200 | 29ms |
2026-07-18 21:00:20 | GET | /api/v1/weather?city=chongqing | 10.8.1.11 | 200 | 28ms |
2026-07-18 21:00:16 | GET | /api/v1/weather?city=nanjing | 10.8.1.18 | 200 | 24ms |
某天下午，我收到了告警：
- CPU 使用率：95%
- 内存使用率：85%
- 响应时间：500ms+
我查了一下监控，发现：
阿里云控制台 - 性能监控
CPU数据库 CPU85%高负载
SQL慢查询500+/天
LAT主库延迟200ms
问题：单机服务器已经到极限了！
我分析了当前的瓶颈：CPU、内存和数据库连接，这三样决定了单台机器还能撑多久。只有先算清楚每一样能承载多少请求，后面的负载均衡和扩容才不会变成盲目地加机器。
CPU
CPU 是这台机器最先撞墙的地方。要判断它到底是不是瓶颈，得先把「每秒来了多少请求」和「单次请求要花多少 CPU」分开看，而不是看到 95% 就直接加机器。
设计流程
CPU
- 步骤 1：用 QPS 乘以单请求 CPU 耗时，估出当前实例实际能扛的请求量
- 步骤 2：用火焰图定位 CPU 热点，区分外部 API 等待和本地真正消耗 CPU 的逻辑
- 步骤 3：据此算出需要的实例数量，把结论写进下一步的负载均衡方案
关注点：CPU 耗时归属、单机承载量与扩容实例数。
瓶颈：
- 每个请求需要调用外部 API
- 数据处理、缓存操作
- 单实例处理能力有限
内存
内存问题最容易被误判成 CPU 问题。真正要算清的是：哪些内存是常驻的、哪些随请求波动，以及请求量继续上涨时哪一部分会先把实例撑爆。
设计流程
内存
- 步骤 1：采集进程常驻内存、堆内存和连接池占用，画出内存随 QPS 变化的曲线
- 步骤 2：把常驻部分（应用实例、连接池）与波动部分（缓存对象、请求缓冲）分开估算
- 步骤 3：按实例规格和峰值内存反推能承载的 QPS，给缓存与连接池各设一个内存上限
关注点：常驻内存与波动内存的拆分，以及单实例的内存上限。
瓶颈：
- 数据库连接池占用内存
- 缓存数据占用内存
- 应用实例会占用固定内存
数据库连接
数据库连接是单机上最容易被漏掉的瓶颈。应用还能再开，但 MySQL 的最大连接数是硬上限，所以要先算出每个请求占用连接多久，再决定是扩应用还是改读写结构。
设计流程
数据库连接
- 步骤 1：查看当前活跃连接数与 max_connections 的差距，同时统计长事务和慢查询占用的连接
- 步骤 2：估算单请求持有连接的平均时长，用它算出连接池大小和单实例可承载的 QPS
- 步骤 3：判断瓶颈归属：连接数不够先扩实例，超过实例承载能力再考虑读写分离
关注点：连接池占用、MySQL 连接上限与单实例可承载的请求量。
瓶颈：
- MySQL 默认最大连接数：151
- 当前使用 50 个，已经占 1/3
- 继续增长会达到上限
发现内容有问题？
告诉我们哪里需要改进。