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 触发直接回收压力。

标签： mysql linux docker nginx curl ai ios keep-alive stream 为什么