Linux性能优化需遵循“观测→定位→干预”分阶段流程：先明确目标与基线，再按硬件→内核→进程→应用逐层诊断，接着针对性优化并验证固化，最终在满足SLA或投入产出比过低时停止。
Linux性能优化没有放之四海而皆准的“一键方案”，但有一套通用、可复现、分阶段的标准流程。核心思路是：先观测、再定位、后干预，避免盲目调参或过早优化。
一、明确目标与基线：别优化错方向
优化前必须回答三个问题：当前系统在做什么？用户感知到的问题是什么？有没有可量化的指标？
- 确认瓶颈类型：是CPU满载、内存OOM、磁盘I/O卡顿、网络延迟高，还是应用层逻辑慢？
- 建立性能基线：用vmstat 1 10、iostat -x 1 5、sar -n DEV 1 5等采集空闲/轻载时的典型值，后续对比才有意义
- 区分真实瓶颈和伪现象：比如top显示CPU 100%，但可能只是单个后台进程短暂爆发，不影响业务——需结合pidstat -u 1看进程级分布
二、分层诊断：从硬件到应用逐层下探
按“硬件 → 内核 → 进程 → 应用”顺序排查，每层只关注本层职责，不越界猜测。
- CPU层：用mpstat -P ALL 1看各核负载是否不均；用perf top抓热点函数；注意软中断（si%高）常源于网卡或定时器，查cat /proc/interrupts
- 内存层：关注free -h中available是否持续偏低；用slabtop查内核对象泄漏；cat /proc/meminfo | grep -E "Swap|Commit"判断交换风险
- I/O层：iostat -x重点看%util（饱和度）、await（响应延迟）、r_await/w_await（读写分离）；若%util低但await高，说明设备响应慢而非忙
- 网络层：用ss -ti看连接重传、RTT；netstat -s查丢包/重置统计；结合iftop或nethogs定位流量大户
三、针对性干预：只改真正影响业务的项
优化动作必须可验证、可回滚，拒绝“听说这个参数能提速”式操作。
- 调整内核参数仅限已证实瓶颈：如TCP调优（net.ipv4.tcp_tw_reuse）、文件句柄（fs.file-max）或IO调度器（blk_mq scheduler），每次只改一个，用sysctl -w临时生效并观察
- 进程级优化优先于系统级：给关键服务绑核（taskset）、调高nice值、限制cgroup资源（memory.max、cpu.weight），比全局改swappiness更安全
- 应用配置比内核参数更有效：数据库连接池大小、JVM堆参数、Nginx worker_connections等，通常带来数量级提升
- 警惕“优化反模式”：关闭transparent_hugepage对Redis有益，但对多数数据库反而有害；过度调大vm.swappiness会加剧swap抖动
四、验证与固化：闭环才算完成
优化后必须回归业务场景验证，不能只看监控数字变好。
- 用相同压测工具（如wrk、fio、sysbench）复现原问题场景，对比TPS、延迟P99、错误率
- 长期观察24小时以上：某些问题（如内存泄漏、连接泄漏）需时间暴露
- 将生效配置写入/etc/sysctl.conf或对应服务systemd unit文件，避免重启失效
- 记录变更清单：改了什么、为什么改、预期效果、实际效果——下次出问题时这是最快溯源依据
基本上就这些。流程本身不复杂，但容易忽略的是“停止优化”的时机：当投入产出比急剧下降，或问题已满足SLA要求，就该收手。真正的性能工程，是平衡、克制与证据驱动的结果。
