linux性能优化 是观测→定位→调优→验证的闭环过程，需先用 top、vmstat、iostat、free、netstat 等命令筛查瓶颈，再用 perf、iotop、tcpdump等深入分析，针对性调整应用、文件系统和内核参数，并通过压测与监控验证效果。
Linux 性能优化不是 堆配置、换硬件，而是从观测到定位、再到调优的闭环过程。关键在“先看清再动手”，避免盲目改参数反而引发新问题。
一、明确瓶颈在哪：用基础命令快速筛查
别急着调内核参数，先用 5 个命令摸清系统当前负载特征：
- top / htop：看 CPU 使用率、运行队列长度（load average）、内存占用、哪个进程吃资源最狠
- vmstat 1：每秒刷新，重点看 red”>r（就绪进程数） 是否持续 > CPU 核数，si/so（swap 交换） 是否非零，bi/bo（磁盘 I /O） 是否突增
- iostat -x 1：查磁盘瓶颈，关注 %util（接近 100% 说明设备饱和）、await（平均等待毫秒，>10ms 需警惕）、r_await/w_await 分离读写延迟
- free -h：看 available 是否充足，buff/cache 占比高属正常，但 swap used 持续增长说明物理内存真不够
- netstat -s 或 ss -s：查网络异常，如 packet receive errors、retransmits 明显上升，可能网卡或 TCP栈 出问题
二、深入定位 热点 ：按场景选择精准 工具
确认大方向后，用更细粒度 工具 锁定根因：
- CPU 高？用 perf top 看函数级 热点，或 pidstat -u 1 查单进程 CPU 时间分布
- 内存慢？用 slabtop 查内核 对象 分配，cat /proc/meminfo 看 PageCache、SReclaimable 等细节，配合 memleak（bpftrace 脚本）找用户态泄漏
- 磁盘慢？用 iotop 找 IO 大户，blktrace + blkparse 分析 IO 路径延迟，确认是应用随机读多、还是存储层响应慢
- 网络卡？用 tcpdump 抓包看重传 / 乱序，bcc 工具集里的 tcplife、tcpretrans 直接统计连接生命周期和重传行为
三、有针对性地调优：不碰通用参数，只改关键项
多数场景无需动 sysctl.conf 全局参数。优先做这几类调整：
- 应用层 ： 数据库 调连接池大小、查询缓存；Web 服务调 worker 进程数与 CPU 绑定（taskset），禁用 transparent_hugepage（对 redis/Mongo 易引发停顿）
- 文件系统：SSD 挂载加 noatime,nodiratime,deadline（或 mq-deadline）；大文件顺序读写可调 vm.swappiness=1 减少 swap 倾向
- 内核轻量干预：高频小包场景调 net.ipv4.tcp_tw_reuse=1；突发连接多时增大 net.core.somaxconn 和 net.ipv4.tcp_max_syn_backlog
- 硬件协同：开启网卡 TSO/GSO、RSS 队列绑定 CPU，NVMe 盘启用 irqbalance 并隔离中断 CPU
四、验证与固化：每次改动必须可测、可回滚
改完不验证 = 白忙活。建议：
- 用相同压测脚本（如 wrk、fio、sysbench）前后对比，至少跑 3 轮取中位数
- 监控加基线标注：用 prometheus+grafana 画出调优前后关键指标曲线（如 P99 延迟、IOPS、context switches/sec）
- 所有修改写进 ansible Playbook 或shell 脚本，注释清楚原因和预期效果；生产环境严禁手动echo 进 /proc
- 保留原始配置备份，确保 10 秒内可回退
基本上就这些。Linux 性能优化不复杂但容易忽略闭环——观测不准就定位偏，定位不清就调错方向，调完不验就埋下隐患。把流程走扎实，90% 的问题自然浮现、自然解决。
