1. 当我们谈论内核调优时在说什么？

每次登录服务器看见"Too many open files"报错时，大家总在群里丢出那个万能解药ulimit -n 65535。但内核调优远不止这么简单，就像给跑车换涡轮增压器，每个参数的调整都在考验我们对系统工作机制的理解。今天我们挑出三块硬骨头——网络栈配置、文件描述符限制和内存交换优化，用真实的战场案例来解读如何驯服Linux内核。

2. 网络栈调优：万级并发连接的奥秘

2.1 TCP协议栈的瓶颈突破

我们服务的双十一压测现场曾遇到诡异现象：当并发连接达到5万时，新连接建立延迟突然暴增。经过排查发现是内核的默认缓冲设置成了瓶颈。

示例（CentOS 7环境）：

# /etc/sysctl.conf
# 增大TCP读写缓冲区范围
net.ipv4.tcp_rmem = 4096 87380 16777216   # 最小/默认/最大值（字节）
net.ipv4.tcp_wmem = 4096 16384 16777216

# 允许TIME-WAIT快速回收
net.ipv4.tcp_tw_reuse = 1

# 最大连接跟踪表项（慎用大内存机器）
net.nf_conntrack_max = 655360

# 半连接队列扩容（防SYN洪水攻击）
net.ipv4.tcp_max_syn_backlog = 65536
net.core.somaxconn = 32768

注释说明：tcp_tw_reuse参数让内核可以重用处于TIME-WAIT状态的socket，但需要配合开启TCP时间戳（默认启用）。连接跟踪表项在NAT环境中特别重要，但大表项会显著消耗内存。

2.2 UDP风暴的应对策略

实时日志采集服务曾因UDP丢包遭遇数据丢失，调整以下参数缓解问题：

# 增大接收缓冲区
net.core.rmem_max = 67108864
net.core.rmem_default = 2097152

# 防止突发流量丢包
net.core.netdev_max_backlog = 300000

# 启用UDP早应答
net.ipv4.udp_early_rmem = 1

实际效果：在每秒处理10万UDP包场景下，丢包率从3%降至0.2%。

3. 文件描述符：打开世界的钥匙

3.1 系统级限制的深水区

当容器化部署的Redis集群报出"Can't open log file"错误时，我们发现：

  1. 用户级限制设置不生效
  2. Systemd服务有自己的小本本
  3. Nofile的hard/soft限制要匹配

示例（Ubuntu 22.04 + systemd）：

# /etc/security/limits.conf
* soft nofile 1024000
* hard nofile 1024000

# /etc/systemd/system/redis.service.d/override.conf
[Service]
LimitNOFILE=1024000

# 验证当前shell限制
ulimit -Sn  # 查看当前soft限制
ss -a | wc -l  # 查看实际打开数

3.2 File descriptor泄漏检测

# 快速定位泄漏进程
lsof -n | awk '{print $2}' | sort | uniq -c | sort -nr | head

# 或更精准的统计
cat /proc/sys/fs/file-nr

4. 内存交换：性能与稳定的跷跷板

4.1 Swappiness的迷思

我们的虚拟化平台曾遇到KVM宿主机的周期性卡顿，最终追踪到swappiness值设置为30导致：

# 临时生效（生产环境慎用）
sysctl vm.swappiness=10

# 永久生效（通常建议物理机1-10，虚拟机5-15）
echo "vm.swappiness=10" >> /etc/sysctl.conf

# 查看页交换统计
sar -B 1  # 每秒的pgscank/pgscand变化

典型案例：将200G内存的MySQL服务器的swappiness从60调至5后，QPS波动幅度降低70%。

4.2 Zswap：更聪明的交换策略

# 检查当前压缩交换是否启用
zcat /sys/module/zswap/parameters/enabled

# 启动参数调整（GRUB_CMDLINE_LINUX添加）
zswap.enabled=1 zswap.max_pool_percent=20

注：Zswap在内存压缩时使用的LZO算法可能影响性能，需结合lrzip等工具监控。

5. 应用场景的三棱镜

  • 高并发网关：TIME-WAIT优化 + 连接跟踪表扩容
  • 实时流处理：UDP缓冲区调整 + 网络中断绑定
  • 内存计算集群：透明大页禁用 + swap完全禁用
  • 容器化部署：cgroup级别的fd限制 + 内存回收调优

6. 技术优缺点的双刃剑

6.1 网络参数调优

  • ✅ 吞吐量提升可达300%
  • ❌ 过大的缓冲区导致内存碎片化
  • ⚠️ 注意关闭端口复用时的NAT问题

6.2 文件描述符调整

  • ✅ 支持百万级长连接
  • ❌ 可能掩盖资源泄漏的根本问题
  • ⚠️ 超过内核fs.nr_open可能导致系统异常

7. 注意事项：调优不是万能药

  • 📌 每次只改一个参数并监控效果
  • 📌 压力测试时注意tuned服务可能重置设置
  • 📌 /proc文件系统的参数可能覆盖/etc/sysctl.conf
  • 📌 云主机某些参数受宿主机限制

8. 总结：通往性能巅峰的山路

内核调优就像中医把脉，既要懂经脉走向（系统原理），又要会望闻问切（监控工具）。记住三个黄金法则：

  1. 先测量再调整，perf/sar/bpftrace是好帮手
  2. 保持参数间的平衡（如缓冲区和内存的平衡）
  3. 文档化每次变更，方便回溯问题

最终的魔法参数并不存在，好的调优方案一定是特定硬件、特定负载、特定场景下的最优解。