linux性能优化需先定位瓶颈再精准干预，避免盲目调参；应结合ss、vmstat、iostat等工具分析真实负载，理解指标含义，建立“现象—机制—调整”闭环认知。
很多人一遇到 Linux 性能问题，就急着调参数、换内核、加硬件，结果问题没解决，系统反而更不稳定。性能优化不是“越激进越好”，而是“先看清瓶颈，再精准干预”。很多所谓“优化操作”，其实既无依据，又破坏系统默认的平衡机制。
盲目修改 sysctl 参数
看到网上教程说“把 net.core.somaxconn 调到 65535 就能抗高并发”，就照着改；发现磁盘 I/O 慢，马上把 vm.swappiness 设成 0。这些操作脱离实际负载和硬件条件，往往适得其反。
- Linux 内核默认值经过大量场景验证，多数情况下比随意调优更稳健
- 修改前必须用 ss -s、netstat -s、cat /proc/net/snmp 等确认对应子系统确实存在异常计数（如大量 “ListenOverflows”）
- swappiness=0 并不等于禁用 swap，在内存压力下可能触发 OOM killer，反而比适度使用 swap 更危险
只看 top 的 %CPU，忽略真正瓶颈
top 显示 CPU 使用率不到 30%，就断定“CPU 没问题”，然后去折腾网络或磁盘。实际上，大量性能问题出在等待态（I/O wait、uninterruptible sleep），而非运行态。
- 用 vmstat 1 观察 wa（I/O wait）和 us/sy 比例，wa 长期 >10% 表示 I/O 是瓶颈
- 用 pidstat -u -w 1 查看进程级上下文切换（cswch/s）和等待时间（wchan），识别频繁阻塞的进程
- 用 iostat -x 1 关注 %util 和 await，注意：%util 接近 100% 不代表磁盘饱和，要结合 r_await/w_await 和 svctm 综合判断
把监控指标当因果，不做归因分析
发现 load average 达到 24，立刻认为“系统过载”，重启服务或扩容。但 load average 只反映运行队列长度 + 不可中断状态进程数，它高可能是短时突发、也可能是 D 状态卡死、还可能是 CPU/IO/内存多维度耦合问题。
- load 高时优先检查 ps aux --sort=-pcpu | head -10 和 ps aux --sort=-pmem | head -10
- 用 cat /proc/loadavg 看三个数值（1/5/15 分钟），判断趋势；配合 dmesg -T | tail 查看是否有内核警告或 block dump
- 对长期高 load，用 perf record -g -a sleep 30 && perf report 定位热点函数，而不是靠猜
用错工具或误读输出
用 free -m 看到 “available” 只有 500MB 就 panic，以为内存快耗尽；或者用 df -h 发现根分区 95% 就立刻清理日志，却没注意到是某个大文件被 rm 但句柄未释放。
- free 中的 available 是内核估算的可分配内存，不是剩余空闲内存；只要没有频繁 OOM 或大量 page cache 回收，不必过度关注
- df 显示满，先运行 lsof +L1 找被删除但仍被进程占用的大文件；再用 du -sh /* 2>/dev/null | sort -hr | head -5 定位真实目录占用
- 用 htop 替代 top 时，注意它默认开启“树状视图”，可能掩盖线程级资源争用，需按 H 切换显示线程
性能优化的核心不是堆参数、不是背命令，而是建立“指标—现象—机制”的闭环认知。每次调整前问一句：这个改动针对哪个可观测现象？是否影响其他子系统？有没有回滚方案？想清楚再动手，省下的不仅是时间，更是稳定性。
