当前位置：首页 > news >正文

Linux 内核调优：不要把所有性能问题都甩给参数

news 2026/7/2 1:29:46

Linux 内核调优：不要把所有性能问题都甩给参数

一、内核参数调优的误区： Only`sysctl -w`不是解决方案

很多运维工程师在碰到性能问题时，第一反应是"调内核参数"。TCP 连接不上？调net.core.somaxconn。内存不够？调vm.swappiness。磁盘 IO 慢？调vm.dirty_ratio。看起来很有道理，但实际上大多数性能问题不是内核参数导致的。

根据我们的生产统计，性能问题的根因分布是：应用代码问题 40%、数据库慢查询 25%、网络架构问题 20%、内核参数问题 15%。如果把所有精力都花在调内核参数上，90% 的问题还是解决不了。

内核参数调优的价值，不是在出问题后去"调"，而是在系统上线前就根据业务特征做合理的默认配置。事后的调优往往收益有限，因为真正影响性能的因素在更上层。

二、必须调的几个关键内核参数

虽然大多数性能问题不是内核参数导致的，但有几个关键参数如果不调，确实会成为瓶颈。这些是经过生产验证的"必调项"：

graph TD A[Linux 内核参数调优] --> B[网络相关] A --> C[内存相关] A --> D[文件系统相关] A --> E[进程调度相关] B --> B1[net.core.somaxconn] B --> B2[net.ipv4.tcp_max_syn_backlog] B --> B3[net.core.netdev_max_backlog] B --> B4[net.ipv4.tcp_tw_reuse] C --> C1[vm.swappiness] C --> C2[vm.overcommit_memory] C --> C3[vm.dirty_ratio] D --> D1[fs.file-max] D --> D2[fs.nr_open] E --> E1[kernel.sched_min_granularity_ns] E --> E2[kernel.sched_wakeup_granularity_ns] style B1 fill:#f9f,stroke:#333 style C2 fill:#bfb,stroke:#333 style D1 fill:#bbf,stroke:#333

1. 网络相关：高并发服务必调

# 放在 /etc/sysctl.d/99-network.conf # TCP 连接队列长度（默认 128 太小） net.core.somaxconn = 4096 net.ipv4.tcp_max_syn_backlog = 8192 # 网卡收包队列（防止丢包） net.core.netdev_max_backlog = 16384 # TIME_WAIT 复用（高并发短连接场景必开） net.ipv4.tcp_tw_reuse = 1 # 扩大端口范围（防止客户端的端口耗尽） net.ipv4.ip_local_port_range = 1024 65535 # TCP 拥塞控制算法（BBR 适合高延迟网络） net.core.default_qdisc = fq net.ipv4.tcp_congestion_control = bbr

2. 内存相关：Redis / MySQL 必调

# 放在 /etc/sysctl.d/99-memory.conf # 控制 swap 使用倾向（0 = 尽量不用 swap，默认 60） vm.swappiness = 1 # 允许 overcommit（Redis 等需要 fork() 的服务必开） vm.overcommit_memory = 1 # 透明大页（THP）会导致 Redis 延迟抖动，建议关闭 # （通过 grub 内核参数 transparent_hugepage=never）

3. 文件描述符限制：所有服务必调

# 放在 /etc/sysctl.d/99-files.conf fs.file-max = 1000000 fs.nr_open = 1000000 # 同时修改 /etc/security/limits.conf * soft nofile 1000000 * hard nofile 1000000

三、不要调的参数：避免画蛇添足

有些参数看起来"可以优化"，但实际调了之后可能适得其反。以下是我们的"不要调"清单：

1.vm.dirty_ratio和vm.dirty_background_ratio

这两个参数控制的是"内存中的脏数据（待写入磁盘的数据）比例"。默认值（20% 和 10%）对大多数场景是合理的。如果调得太低（比如 5%），会导致应用频繁触发 IO，反而变慢；如果调得太高（比如 50%），会导致突发 IO 时系统卡顿。

除非你的业务是特定的数据库或消息队列，否则不要动这两个参数。

2.kernel.sched_*进程调度相关参数

Linux 的 CFS（Completely Fair Scheduler）调度器在绝大多数场景下都表现良好。除非你在跑实时任务或实时性要求极高的服务，否则不要调这些参数。

我们曾经因为"听说调低sched_min_granularity_ns可以提高交互响应"而调了这个参数，结果导致 CPU 密集型任务的 throughput 下降了 15%。内核调度器的默认参数，通常是内核社区经过大量测试得出的合理值，不要随意改动。

3.net.ipv4.tcp_fin_timeout

这个参数控制的是 TCP FIN-WAIT-2 状态的超时时间。默认值是 60 秒，有些"优化指南"会建议改成 30 秒或更低。但这样做的风险是：如果客户端真的需要 60 秒来关闭连接，改低了这个参数会导致连接被强制关闭，可能引发应用错误。

四、内核参数调优的正确流程

内核参数调优不是"改了就完事"，而是一个有完整验证流程的工程实践：

1. 基准测试（改动前） └── 用 ab / wrk / fio 等工具记录基准性能数据 2. 改动参数（一次只改一个） └── 修改 /etc/sysctl.d/*.conf，然后 sysctl -p 生效 3. 回归测试 └── 用同样的基准测试，对比改动前后的性能差异 4. 灰度验证 └── 先在一台节点上验证，观察 1-2 天无异常后再推广 5. 文档记录 └── 记录改动原因、预期效果、实际效果、回滚方法

关键原则：一次只改一个参数。如果同时改了多个参数，后期排查问题时无法确定是哪个参数导致的副作用。

# 内核参数基准测试脚本（简化版） import subprocess import time import json def benchmark_sysctl(param: str, values: list): """对比不同参数值的性能影响""" results = {} for value in values: # 修改参数 subprocess.run(f"sysctl -w {param}={value}", shell=True) # 等待参数生效 time.sleep(2) # 运行基准测试（这里用 wrk 作为例子） result = subprocess.run( "wrk -t12 -c400 -d30s http://localhost:8080", shell=True, capture_output=True, text=True ) # 解析 wrk 输出，提取 QPS 和延迟 output = result.stdout qps = parse_qps(output) latency = parse_latency(output) results[value] = {"qps": qps, "latency": latency} # 重要：测试完后恢复默认值 restore_default(param) return results def restore_default(param: str): """恢复参数到默认值""" defaults = { "net.core.somaxconn": 128, "vm.swappiness": 60, # ... 其他参数的默认值 } default_value = defaults.get(param, None) if default_value: subprocess.run(f"sysctl -w {param}={default_value}", shell=True)