linux性能优化需先定位瓶颈再针对性调整，涵盖监控、cpu、内存、磁盘、网络五方面，强调“测—改—验”循环验证效果。
Linux性能优化不是堆硬件或改几个参数就能见效的事，关键在定位瓶颈、理解资源协作逻辑、做有针对性的调整。下面从监控、CPU、内存、磁盘和网络五个最常出问题的方向，给出可立即上手的操作步骤和判断依据。
一、先看清瓶颈在哪：用对工具比盲目调参重要十倍
别一上来就改内核参数。先运行以下命令快速摸清系统当前压力源：
- top 或 htop：看 CPU 使用率是否持续超 80%，哪个进程占 CPU 最高（注意看 %CPU 和 RES 列）
- free -h：重点看 red">available 值，不是 free；若 available 长期低于 10% 且 buff/cache 没明显增长，说明真缺内存
- iostat -x 1：看 %util 是否长期 > 85%，同时 await 和 r_await/w_await 是否显著升高（> 20ms 值得查）
- ss -s 或 netstat -s：检查是否有大量重传（retransmitted）、连接失败（failed connection attempts）或 TIME_WAIT 堆积
二、CPU 瓶颈常见处理方式
CPU 高不等于程序写得差，也可能是调度或中断干扰：
- 用 pidstat -u 1 找出真正耗 CPU 的线程（TID），再结合 ps -T -p [PID] 查线程名
- 检查软中断是否偏高：cat /proc/softirqs，若 NET_RX 或 TIMER 占比异常，可考虑绑定网卡中断到特定 CPU（通过 /proc/irq/*/smp_affinity_list）
- 对高并发服务（如 Nginx、Redis），确认是否启用了多进程/多线程 + CPU 绑定（taskset 或 systemd 的 CPUAffinity）
三、内存不够用？先分清是真缺还是假压
Linux 会主动用空闲内存做 page cache，这属于正常行为：
- 观察 cat /proc/meminfo 中的 MemAvailable，它已排除不可回收缓存，才是真实可用内存
- 若应用频繁 OOM，检查 dmesg -T | grep -i "killed process"，确认是否被 oom_killer 杀掉；可临时调低 vm.swappiness=10 减少换出倾向
- Java 类应用记得设合理堆大小（-Xms/-Xmx），避免 JVM 向系统申请远超实际需要的虚拟内存
四、磁盘 I/O 慢？从队列和调度器入手
SSD 和 HDD 对调度策略敏感度不同：
- 查当前 IO 调度器：cat /sys/block/[DEVICE]/queue/scheduler；SSD 推荐 none（即 kyber 或 mq-deadline），HDD 可用 bfq
- 用 iotop -o 找出只读/只写的重 IO 进程；数据库类服务建议单独挂载磁盘，并关闭 atime（mount -o remount,noatime /data）
- 避免日志和数据混放；rsyslog、journal 日志量大时，可限制大小并启用轮转（/etc/systemd/journald.conf 中设置 SystemMaxUse=512M）
五、网络延迟高或丢包？别只盯带宽
很多“网络慢”其实是连接管理或协议栈配置问题：
- 检查连接数上限：cat /proc/sys/net/core/somaxconn（默认 128，高并发服务建议调至 65535）
- TIME_WAIT 过多？可开启 net.ipv4.tcp_tw_reuse = 1（仅客户端有效）或 net.ipv4.tcp_fin_timeout = 30
- 内网传输慢？确认是否启用了 TCP SACK 和窗口缩放：net.ipv4.tcp_sack=1、net.ipv4.tcp_window_scaling=1
基本上就这些。优化不是一步到位，而是“测—改—验”循环：每次只动一个变量，用相同负载反复验证效果。参数调得好不好，最终要看业务响应时间和错误率有没有真实改善。
