57 lines
2.1 KiB
Markdown
57 lines
2.1 KiB
Markdown
# 11.7 性能调优
|
||
|
||
:::tip 概述
|
||
调优顺序：**先观测、再定位、后调参**。可观测面有三层：Prometheus 指标（宏观）、服务监控页（主机）、SQL debug 日志（微观）。本页给出常见瓶颈与对应手段。
|
||
:::
|
||
|
||
## 调优顺序
|
||
|
||
```text
|
||
① /metrics 看哪类路由耗时高、错误率高
|
||
② 服务监控页看主机资源（CPU/内存/goroutine）
|
||
③ SQL debug 定位慢查询
|
||
④ 按瓶颈类型施加对应手段
|
||
⑤ 复测指标
|
||
```
|
||
|
||
## 数据库层
|
||
|
||
| 症状 | 手段 |
|
||
|---|---|
|
||
| 慢查询 | 高频列补索引（idx_{表}_{列}）；核对是否 LIKE 前置通配 |
|
||
| 连接耗尽 | 调 database 连接池（maxOpenConns/maxIdleConns/connMaxLifetime），核对应用与 MySQL 两侧 |
|
||
| 大分页深翻 | 避免大 offset；业务上限 pageSize 500 已兜底 |
|
||
| 频繁字典查询 | 字典缓存已内置；确认未被频繁 Refresh 打穿 |
|
||
|
||
## 应用层
|
||
|
||
| 症状 | 手段 |
|
||
|---|---|
|
||
| goroutine 突增 | 监控页观察趋势；排查泄漏（未收尾的 goroutine、阻塞 channel） |
|
||
| 内存增长 | 大查询/导出是否一次载入过大结果集（导出走流式/分批） |
|
||
| 接口整体变慢 | 看限流是否误伤、日志是否过度（logQuery 巨量） |
|
||
| 日志盘涨 | 校准 job.logRetentionDays；zap 轮转配置 |
|
||
|
||
## 缓存层
|
||
|
||
- Redis 命中率低 → 检查键 TTL 与失效策略
|
||
- 降级内存模式 → 修复 Redis（多实例下内存模式语义退化）
|
||
- 大 key 排查 → Info memory 分区 + 键空间抽样
|
||
|
||
## 限流与入口
|
||
|
||
- 公网收敛 rateLimit.limit（默认 120/min/IP 已可用）
|
||
- Nginx 层配连接/速率限制作为第一道闸
|
||
- 上传大小 maxSize 与 client_max_body_size 对齐，防大文件打内存
|
||
|
||
## 容量规划参考
|
||
|
||
- 无状态应用可横向扩（多实例共享 Redis/MySQL；限流计数 Redis 共享）
|
||
- 读压力大优先加只读库/缓存，而非盲目加应用实例
|
||
- 监控告警：按 route 维度配 P95 耗时与错误率阈值
|
||
|
||
## 相关
|
||
|
||
- [5.17 链路追踪与指标](/zh/core/trace-metrics.html)
|
||
- [11.10 故障排查手册](/zh/deploy/troubleshooting.html)
|