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

Linux性能优化需聚焦瓶颈：CPU限频、磁盘随机IO、内存脏页策略、TIME_WAIT滥用，每项均配诊断命令与实操方案。

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

Linux性能优化不是堆参数，而是盯住瓶颈、快速验证、小步迭代。高频场景下，真正卡住业务的往往就那几个点：CPU调度失衡、磁盘I/O饱和、内存压力误判、网络连接耗尽。下面按实战频率排序，直击最常出问题的环节，每项都附可立即执行的命令和判断逻辑。

很多服务跑着跑着变慢，top 显示 CPU 使用率 90%+，但 uptime 的 load *erage 却只有 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

iostat -x 1 看到 %util 接近 100%，但 await 高、r/s w/s 也高，*gqu-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

free -h 显示 *ailable 还有 4G，但系统突然杀掉 MySQL 进程 —— 很可能因为 dirty_ratio / dirty_background_ratio 设置过高，或应用大量 mmap + MAP_POPULATE 触发直接回收压力。

Text Mark

处理文本内容的AI助手

113 查看详情 Text Mark

查当前脏页策略：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）观察是否缓解

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