Linux性能优化需聚焦瓶颈：CPU限频、磁盘随机IO、内存脏页策略、TIME_WAIT滥用，每项均配诊断命令与实操方案。
Linux性能优化不是堆参数，而是盯住瓶颈、快速验证、小步迭代。高频场景下，真正卡住业务的往往就那几个点：CPU调度失衡、磁盘I/O饱和、内存压力误判、网络连接耗尽。下面按实战频率排序，直击最常出问题的环节，每项都附可立即执行的命令和判断逻辑。
CPU高但负载低？先看是不是被限制了
很多服务跑着跑着变慢，top 显示 CPU 使用率 90%+，但 uptime 的 load average 却只有 0.3 —— 这大概率是 cgroups 限频或 CPU 配额（如 Docker 的 --cpus=0.5）导致的“假高负载”。
- 查进程是否在受限组：
cat /proc/<PID>/cgroup，看是否在/docker/xxx或/kubepods/xxx下 - 查实际可用 CPU 配额：
cat /sys/fs/cgroup/cpu,cpuacct/<group-path>/cpu.cfs_quota_us和cpu.cfs_period_us，比值小于 100000 就说明被限了 - 临时解除限制测试（仅调试）：
echo -1 > cpu.cfs_quota_us
磁盘慢？别急着换SSD，先确认是不是随机写+小文件
iostat -x 1 看到 %util 接近 100%，但 await 高、r/s w/s 也高，avgqu-sz 大于 1 —— 典型的小文件随机 IO 场景，比如日志轮转、数据库 WAL 写入、容器镜像拉取。
- 用
pidstat -d 1定位具体进程的读写模式（重点关注 kB_rd/s、kB_wr/s 和 IOPS） - 对日志类服务，关闭 fsync（如 rsyslog 的
$ActionFileEnableSync off）或切到 buffer 模式 - 数据库类，检查 innodb_flush_log_at_trx_commit 是否为 1（生产建议 2），并确认 log file size 是否过小导致频繁 checkpoint
内存充足却 OOM？可能是内核没及时回收 page cache
free -h 显示 available 还有 4G，但系统突然杀掉 MySQL 进程 —— 很可能因为 dirty_ratio / dirty_background_ratio 设置过高，或应用大量 mmap + MAP_POPULATE 触发直接回收压力。
- 查当前脏页策略：
sysctl vm.dirty_ratio vm.dirty_background_ratio vm.dirty_expire_centisecs - 若 dirty_ratio ≥ 30，且业务有突发写（如批量导入），建议调低至 15～20，避免一次刷盘卡死
- 对只读为主的服务（如静态 Web），可临时
echo 1 > /proc/sys/vm/drop_caches（仅释放 page cache，不影响 slab）观察是否缓解
TIME_WAIT 太多连不上？不是要改 net.ipv4.tcp_tw_reuse
ss -s 显示 65000+ TIME_WAIT，且新连接失败，第一反应不是开 tw_reuse，而是先确认是不是短连接滥用（如 HTTP 没复用、脚本循环起 curl）。
- 用
ss -tan state time-wait | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -10查集中来源 IP，定位客户端行为 - 服务端确需承载海量短连时，再启用：
sysctl -w net.ipv4.tcp_tw_reuse=1（仅对客户端有效），配合net.ipv4.tcp_fin_timeout=30 - 更治本：让上游加 Connection: keep-alive，或 Nginx 做 upstream keepalive
基本上就这些。不复杂但容易忽略——优化不是调参比赛，是把“哪里慢”变成“为什么慢”，再变成“改哪一行配置或代码”。每次只动一点，用 before/after 的 iostat、pidstat、ss 对比，效果立现。
