调优流程与优先级
建立基线 → 证明瓶颈 → 单变量变更 → 验证效果 → 固化与观察。
判断依据
- 基线保持同业务负载、指标和时间窗；通过日志、指标、队列/限额证明瓶颈。
- 单变量变更写明目标、范围与回退；验证 P95/P99、错误率、资源压力。
- 优先级：减少无效工作 → 修复配置 / 代码 → 调整资源与容量 → 仅在有证据时修改内核或硬件参数。
注意事项
- 配置入库；无改善则回退。
- 说明：本图是调优决策与配置入口；“参数名=”仅标识可配置项，不能直接执行。不同内核、systemd 与发行版的支持需现场核对。
- 各命令独立执行；SERVICE / PID / CT / POD / NS 须替换。变更前记录原值；修改后回读生效值并按同负载验证，不预设统一最优参数。
01 应用与服务配置
围绕应用延迟、错误率、连接池/线程池、GC 与慢查询取证。
命令
journalctl -u SERVICE --since "10 min ago"
nginx -t
systemctl cat SERVICE
nginx -t && systemctl reload nginx
判断依据
- 应用原生配置 / 环境配置；并发、超时、连接复用
- 复测业务成功率与 P95/P99，核查依赖压力。
注意事项
- 配置纳入版本管理；先校验，再按服务机制重载。
- nginx -t && systemctl reload nginx 为原图 Nginx 示例，校验后重载服务。
02 CPU 与并发预算
根据各核使用情况和目标 cgroup 节流情况，核查并发与 CPU 预算。
命令
mpstat -P ALL 1 5
pidstat -u -w -p PID 1 5
systemctl show SERVICE -p CPUWeight -p CPUQuotaPerSecUSec
systemctl edit SERVICE
判断依据
- 目标 cgroup v2：cpu.stat / cpu.max
- [Service]：CPUWeight= / CPUQuota=
- CPUWeight 调整竞争份额；CPUQuota 约束 CPU 时间。
- 同时优化并发与容量，观察节流和业务时延。
注意事项
- systemctl edit SERVICE 是服务配置变更入口。
- 服务 drop-in 入库；按变更流程加载配置并验证生效。
03 内存与服务边界
先修复泄漏、缓存或大查询，再设置资源预算。
命令
free -h
pidstat -r -p PID 1 5
systemctl show SERVICE -p MemoryHigh -p MemoryMax
systemctl edit SERVICE
判断依据
- 目标 cgroup v2：memory.events / memory.max
- [Service]：MemoryHigh= / MemoryMax=
- MemoryHigh 用于回收 / 节流；MemoryMax 是硬上限。
注意事项
- systemctl edit SERVICE 是服务配置变更入口。
- 不盲目禁用 swap、清缓存；核查 OOM 与业务时延。
04 文件句柄与连接资源
先判断句柄泄漏、池耗尽还是合理容量不足。
命令
cat /proc/PID/limits
lsof -p PID
ss -s
ss -lntp
systemctl show SERVICE -p LimitNOFILE
systemctl edit SERVICE
判断依据
- [Service]：LimitNOFILE=；应用连接上限同步核查。
- 服务限制以实际进程为准；shell 的 ulimit 不代替服务配置。
注意事项
- systemctl edit SERVICE 是服务配置变更入口。
- 提高限制前确认应用兼容性，并核算下游连接预算。
05 存储、日志与 I/O
优先优化查询、批量 I/O、日志轮转、云盘 IOPS 与吞吐。
命令
iostat -xz -y 1 5
pidstat -d -p PID 1 5
df -hT
df -i
lsof +L1
logrotate -d /etc/logrotate.conf
判断依据
- 服务争用场景：[Service] 的 IOWeight=（需环境支持）。
- IOWeight 是竞争权重，效果受内核、块设备与调度器影响。
- 验证 await、队列与业务时延；空间清理后确认释放。
注意事项
06 网络队列与内核参数
先核查应用监听/backlog、重传、丢包与链路容量。
命令
ss -lntp
ss -tin
ip -s link
ip route get 10.0.0.20
ethtool -S IFACE
sysctl -n net.core.somaxconn
sysctl -p /etc/sysctl.d/90-app.conf
判断依据
- 配置写入 /etc/sysctl.d/90-app.conf。
- 回读参数并复测；避免套用整包“万能优化”配置。
注意事项
- 仅有证据时修改对应参数，保留原值与回退步骤。
- sysctl -p /etc/sysctl.d/90-app.conf 会应用该文件中的配置。
容器与 K8s 资源治理
调工作负载配置，核对目标 cgroup，发布后验证实际限额。
命令
kubectl describe pod POD -n NS
kubectl top pod -n NS
docker inspect CT
kubectl diff -f manifest.yaml
判断依据
- 在工作负载配置中调整 resources.requests / resources.limits；Docker / Compose 在部署配置中固化资源限制。
- kubectl diff -f manifest.yaml → 经团队发布流程变更 → 核查新 Pod 状态、重启、节流、OOM 与服务指标。
- CPU 限额可能造成节流；内存上限触发容器 OOM；requests 影响调度与资源分配。数值来自实测容量规划。
注意事项
- 主机 systemd 的配置不代替 K8s 工作负载配置；按实际资源控制层管理，避免互相覆盖。
按需专项调优
离开通用主线，不等于工具失效；按环境和专项需求选择。
命令
tuned-adm active
tuned-adm recommend
判断依据
- RHEL 系环境的 TuneD：先检查配置档案。
- 延迟 / 绑核 / NUMA / 流控专项：taskset / numactl / ionice / tc；按拓扑、调度器与网络方案选择。
- MegaCli / hdparm / chcpu / tune2fs 等工具由硬件型号、文件系统与专项需求决定。
注意事项
