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、网络四块的协作关系理清楚，大多数性能问题一眼就能看出卡在哪。
