Linux性能如何优化_高频场景实战指导更易上手【技巧】

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</pid>，看是否在 /docker/xxx 或 /kubepods/xxx 下
• 查实际可用 CPU 配额：cat /sys/fs/cgroup/cpu,cpuacct/<group-path>/cpu.cfs_quota_us</group-path> 和 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 触发直接回收压力。

Text Mark

处理文本内容的AI助手

113

查看详情

• 查当前脏页策略：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 对比，效果立现。

以上就是Linux性能如何优化_高频场景实战指导更易上手【技巧】的详细内容，更多请关注php中文网其它相关文章！