掌握基础监控命令是性能优化前提，需理解top、vmstat等输出含义并培养数字敏感度；定位瓶颈须分层验证，结合工具深入内核机制；构建可观测体系实现可持续优化。
掌握基础监控命令，建立系统直觉
刚接触性能优化时，别急着调参数或改内核。先熟练使用 top、htop、vmstat、iostat、netstat、ss、free 这些命令，理解它们输出中关键字段的含义：比如 load average 不是 CPU 使用率，而是就绪队列长度；%wa 高说明 I/O 等待严重；si/so 非零可能暗示内存压力大导致频繁换页。
建议每天花 10 分钟在测试机上运行 vmstat 1 5 和 iostat -x 1 5，结合业务负载变化观察数值波动，慢慢形成“数字敏感度”。
定位瓶颈要分层，不靠猜靠证据
性能问题通常发生在某一层：CPU、内存、磁盘 I/O、网络、应用逻辑或锁竞争。优化前必须明确瓶颈在哪，否则盲目调整只会掩盖真实问题。
- CPU 瓶颈：看 us（用户态） 和 sy（内核态） 是否持续超 70%，再用
perf top或pidstat -u 1找热点函数或进程 - 内存瓶颈：关注 available 是否持续偏低、pgpgin/pgpgout 是否激增、slabinfo 中 dentry/inode 缓存是否异常膨胀
- I/O 瓶颈：看 await > 10ms、%util 接近 100% 且 avgqu-sz 较大，再结合
iostat -x的 r_await/w_await 判断是读还是写拖慢 - 网络瓶颈：用
ss -s看连接状态分布，netstat -s查丢包重传，tcpdump+Wireshark抓包分析延迟来源
深入内核机制，理解参数背后的逻辑
调优不是改 /proc/sys 下的数字，而是理解这些接口控制的是什么行为。例如：
-
/proc/sys/vm/swappiness影响的是内核回收 page cache 和 swap out 匿名页的倾向性，不是“是否启用 swap” -
/proc/sys/net/ipv4/tcp_tw_reuse依赖于时间戳选项开启（net.ipv4.tcp_timestamps=1），否则无效 -
/sys/block/*/queue/scheduler对 SSD 应设为 none 或 mq-deadline，而机械盘常用 bfq -
/proc/sys/kernel/sched_min_granularity_ns调小可提升交互响应，但会增加调度开销，需权衡
推荐通读 《Linux Performance》（Brendan Gregg） 第 2–4 章，配合 man 7 signal、man 7 epoll、Documentation/admin-guide/mm/ 等内核文档加深理解。
构建可观测体系，让优化可持续
单次调优容易回退，长期稳定依赖可观测性。从简单到复杂逐步落地：
- 用 collectd 或 node_exporter 采集基础指标，接入 Prometheus + Grafana 做趋势分析
- 对关键服务加 eBPF 工具链（如
bpftrace、libbpf-tools）做低开销深度追踪，比如观察某个 syscall 的延迟分布或文件打开失败原因 - 记录每次变更的时间、配置项、预期效果和验证方式，形成可复现的 优化档案
- 在 CI/CD 流程中加入基础性能检查点（如启动耗时、内存增长斜率、P99 响应延迟）
真正的专家不是知道最多参数的人，而是能快速建立假设、设计验证路径、并用数据闭环结论的人。
