Linux性能优化需先定位瓶颈再精准干预：CPU（高%us/%sy、r值超核数）、内存（available近0、si/so频繁）、磁盘（%util>80%且await>50ms）、网络（连接堆积、带宽满载吞吐低）；禁盲目清缓存、设swappiness=0或禁THP；推荐htop、iostat -xz 1、systemd-run限资源及调watermark_scale_factor，坚持监控→定位→验证闭环。
Linux性能优化不是“调几个参数就变快”，而是先看清瓶颈在哪，再动最小的手术。很多新手一上来就改swappiness、清缓存、关THP，结果系统更卡——因为根本没搞清问题出在CPU、内存、磁盘还是网络。
别一上来就调参数：先确认瓶颈类型
系统慢 ≠ 性能差，得看是哪类资源扛不住：
-
CPU瓶颈：top里
%us或%sy长期超80%，r（运行队列）值持续大于CPU核心数；进程响应延迟高，但磁盘和网络不忙 -
内存瓶颈：free显示
available接近0，si/so（swap in/out）频繁，pgmajfault飙升；dmesg里出现Out of memory: Kill process -
I/O瓶颈：iostat中
%util > 80%且await明显升高（如>50ms），top里%wa常超30%，但CPU空闲多 -
网络瓶颈：ss -s显示
inuse连接数暴涨，netstat发现大量TIME_WAIT或ESTABLISHED堆积，带宽打满但应用吞吐上不去
新手最常踩的3个坑
这些操作看似“优化”，实则掩盖问题、引发新故障：
-
盲目清缓存：
echo 3 > /proc/sys/vm/drop_caches——缓存本是Linux加速的关键机制，清掉反而让后续读写全走磁盘，瞬间拖垮I/O。除非调试特定缓存行为，否则生产环境禁用 -
把
swappiness直接设为0——这不等于禁用swap，而是让内核极度抗拒换出页面；一旦内存突发吃紧，kswapd来不及回收，直接触发OOM Killer杀进程。建议设为10，平衡响应与稳定性 -
禁用所有透明大页（THP）却不评估业务——对数据库、Java应用等大内存服务，THP能显著降低TLB miss；盲目
echo never可能让延迟升高。应先用perf stat -e 'syscalls:sys_enter_mmap' -p PID观察内存映射频率再决策
真正有效的基础优化动作
不依赖玄学，只做有依据、可验证的小改动：
-
用
htop代替top：支持鼠标、颜色区分、垂直滚动，一眼识别僵尸进程、高线程数进程、内存泄漏迹象 -
加一句
iostat -xz 1查磁盘：重点关注r/s + w/s（IOPS）、rkB/s + wkB/s（吞吐）、avgqu-sz（队列深度）——比单看%util更能定位是设备慢还是请求压得太狠 -
限制非关键进程资源：用
systemd-run --scope -p MemoryLimit=512M -p CPUQuota=20% ./script.sh防止后台任务吃光资源，比nice更可靠 -
检查
/proc/sys/vm/watermark_scale_factor：默认值10太保守，内存充足时可调至50~100，让kswapd更早异步回收，避免min水线触达导致进程卡顿
基本上就这些。优化不是堆参数，而是建立“监控→定位→验证”的闭环。每次改完，用stress-ng或真实负载跑5分钟，对比前后uptime、vmstat 1 10、pidstat -u 1 10三组数据——有变化才叫有效。
