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%的问题自然浮现、自然解决。
