Linux性能优化需聚焦CPU、内存、磁盘IO、网络四大维度：CPU要查上下文切换与软中断；内存应合理设swappiness而非禁swap；磁盘IO需区分慢盘与队列拥堵；网络要调端口范围与conntrack参数。
Linux性能优化不是堆硬件或调几个参数就完事，关键在理解瓶颈在哪、影响谁、怎么验证改动有效。盲目改sysctl、关swap、调OOM分数，反而容易引发更隐蔽的故障。下面从四个最常出问题的维度讲清楚怎么做才真正提升稳定性。
CPU：别只盯%us，先看上下文切换和软中断
top里看到CPU使用率高，不等于程序写得差。可能是频繁进程切换（context switch）、软中断（softirq）压满一个核，或者中断都集中在一个CPU上。
- 用 vmstat 1 看 cs（每秒上下文切换）是否持续超 10k；若高，再用 pidstat -w 1 找频繁切换的进程
- 查软中断分布：cat /proc/softirqs，配合 mpstat -P ALL 1 看哪个CPU被NET_RX占满——这时要开RPS/RFS或调整网卡中断亲和性（smp_affinity）
- 避免“CPU空转等锁”：用 perf record -e sched:sched_switch -g sleep 10 抓调度栈，定位自旋锁或互斥锁争用点
内存：swap不是敌人，但swappiness设0可能更糟
很多人一见swap就panic，直接vm.swappiness=0。这会让内核彻底放弃换出匿名页，在内存紧张时只能触发OOM killer——杀掉大进程，服务直接中断。
- 对数据库、Java应用这类内存大户，swappiness=1~10 更稳妥：允许换出冷页，但不抢cache
- 用 slabtop 查内核对象缓存（如dentry、inode）是否暴涨，可能是文件操作激增或泄漏，不是加内存能解决的
- 检查 /sys/kernel/mm/transparent_hugepage：对延迟敏感服务（如Redis、Kafka），建议设为madvise而非always，避免THP分配卡顿
磁盘IO：iowait高？先分清是慢设备、队列深，还是锁竞争
iostat显示%util=100%不等于磁盘真的跑满了。可能是队列堆积（avgqu-sz高）、响应时间（r_await/w_await）飙升，或单个进程死锁式刷盘。
- 用 iostat -x 1 看 await > 10ms 且 svctm 接近 await → 真慢盘；若 await 高但 svctm 很低 → 队列堵了（检查nr_requests、read_ahead_kb）
- 查谁在狂写：iotop -oPa（只看实际IO进程），注意区分 buffered write 和 direct write
- SSD场景下，禁用barrier（mount -o barrier=0）可降延迟，但必须确保有UPS或写缓存电池——否则断电丢数据
网络：连接数上不去？往往卡在本地端口、TIME_WAIT或连接跟踪
明明ss -s说已用连接才几百，却报“Cannot assign requested address”，大概率是本地端口耗尽或conntrack表满。
- 扩本地端口范围：net.ipv4.ip_local_port_range = 1024 65535，同时调大 net.ipv4.tcp_fin_timeout（慎用tcp_tw_reuse，NAT环境下易冲突）
- 查conntrack状态：conntrack -S 看hash bucket使用率，超80%就要加 net.netfilter.nf_conntrack_buckets（需重启nf_conntrack模块）
- 高并发短连接服务（如API网关），关闭syncookies（net.ipv4.tcp_syncookies=0），并调大 net.core.somaxconn 和 net.ipv4.tcp_max_syn_backlog
基本上就这些。优化不是一步到位，而是“监控→定位→假设→验证→固化”。每次只改一项，用stress-ng或真实流量压测前后对比，比背参数有用得多。
