Linux性能优化核心是定位瓶颈+精准干预，关键看CPU（%us/%sy/%wa）、内存（MemAvailable/PSS）、磁盘（%util/await）、网络（丢包/队列溢出）四大指标，坚持“观察→假设→验证→收敛”循环。
Linux性能优化不是堆参数、不是盲目调优，核心在于定位瓶颈 + 精准干预。系统资源就那么几样：CPU、内存、磁盘I/O、网络，问题一定出在其中一环或它们的协同上。先看清“哪堵了”，再决定“怎么通”，这才是高效优化的起点。
看懂指标，比调参更重要
很多同学一上来就改sysctl、调ulimit、换调度器，结果压根没搞清真实瓶颈。真正该花时间的是读懂基础监控信号：
-
uptime / proc/loadavg：看平均负载，但注意——它包含等待CPU和等待不可中断状态（如磁盘）的进程，高负载不等于CPU满，得结合
top或htop里的%CPU和%wa（iowait）一起看 -
free -h：关注
available列，不是free；buff/cache高是正常现象，内核会自动回收，别急着echo 3 > /proc/sys/vm/drop_caches -
iostat -x 1：重点看
%util（设备忙时占比）、await（I/O平均等待毫秒）、r_await/w_await，单个设备%util持续超80%+ await飙升，基本锁定磁盘瓶颈 -
ss -s 或 netstat -s：查连接数、重传、丢包、socket队列溢出（如
prune、overflow字段），网络卡顿往往藏在这里
CPU高？先分清是“忙”还是“等”
CPU使用率高≠程序写得差。用pidstat -u 1或perf top定位热点函数，但更关键的是看上下文：
- 如果
%sy（系统态）占比高，可能是频繁系统调用——检查是否小文件读写多、锁竞争激烈、或strace看到大量read/write/futex - 如果
%us（用户态）高且集中在某进程，用perf record -g -p PID抓火焰图，看是不是算法复杂度问题或未用缓存 - 如果
%wa高，说明CPU在等I/O，此时降CPU占用没意义，得去查磁盘或慢SQL、同步日志等源头
内存不够用？先确认是不是真缺
Linux的OOM Killer不是bug，是保命机制。触发前通常有迹可循：
- 看
dmesg | tail是否有Out of memory: Kill process记录，再查对应进程的内存模型（RSS、VSS、PSS） - 用
smem -w看各进程实际物理内存占用（PSS更准），比ps aux --sort=-%mem靠谱 - 检查
/proc/meminfo中MemAvailable是否持续逼近0，同时Inactive(file)很低——说明page cache被大量挤占，可能是应用内存泄漏或vm.swappiness设太高导致过度swap - 避免滥用
vm.overcommit_memory=2，它强制限制分配，反而让malloc失败更早，掩盖真实问题
磁盘和网络：别只盯带宽，要看延迟和队列
SSD再快，遇上随机小IO或长队列也会拖垮系统：
- 用
iotop看实时IO吞吐和延迟，配合cat /proc/PID/io查某进程的读写字节数、取消次数（cancelled_write_bytes） - 检查块设备队列深度：
cat /sys/block/sda/queue/nr_requests，机械盘建议32~64，NVMe可调到256以上；但调高不解决根本，得配合应用层批量写、异步IO - 网络方面，
net.core.somaxconn要≥应用listen backlog，net.ipv4.tcp_tw_reuse可加快TIME_WAIT复用，但前提是客户端是NAT环境且时间戳开启 - 别忽略本地回环（lo）和容器网络（如cni0、docker0）的丢包，
ip -s link show里看rx/tx dropped突增，常因缓冲区不足或中断风暴
基本上就这些。优化不是一步到位，而是“观察→假设→验证→收敛”的循环。工具只是眼睛，逻辑才是大脑。把CPU、内存、IO、网络四块的协作关系理清楚，大多数性能问题一眼就能看出卡在哪。
