Linux 基础体系 · 第 34/85 篇。示例面向现代主流 Linux 发行版；发行版差异、权限和生产风险会明确说明。

Linux sysctl 与内核参数：来源、持久化、风险、压测和回滚

在 Linux 中，“内核参数”不是一个单一接口：

  • 有些参数只能在内核启动时通过内核命令行设置；
  • 有些参数在运行时暴露为 /proc/sys，可通过 sysctl 读取和修改；
  • 有些参数属于模块参数，位于 /sys/module/<module>/parameters/；
  • 有些所谓“参数”其实是资源限制，例如 RLIMIT_NOFILE，由 ulimit、PAM 或 systemd 管理；
  • 有些值来自发行版配置文件、启动加载器、容器运行时或编排系统。

如果不先区分这些来源，就容易出现“命令执行成功但重启失效”“改了 sysctl 却没有解决文件句柄不足”“压测结果变好但生产故障更严重”等问题。

一、先区分：内核启动参数、sysctl 和资源限制

1. 内核启动参数

内核启动参数是传递给内核映像或内核模块的参数，通常来自引导加载器的 linux 或 linuxefi 命令行。例如：

quiet splash
root=/dev/mapper/vg-root
systemd.unified_cgroup_hierarchy=1

系统启动后可以查看实际使用的内核命令行：

cat /proc/cmdline

输出是内核启动时接收到的参数。它描述的是启动过程中的输入，不是所有参数的当前状态。

某些启动参数只能在启动时生效，例如改变早期内存、CPU、IOMMU 或根文件系统行为的参数。修改它们通常需要：

  1. 修改 GRUB、systemd-boot 或其他引导加载器配置；
  2. 重新生成引导配置；
  3. 重启；
  4. 检查 /proc/cmdline 和相关运行时状态。

发行版的具体命令不同，不能把某个发行版的 GRUB 命令当作通用接口。

2. sysctl 参数

sysctl 是一组运行时内核参数接口。大多数 sysctl 参数通过 procfs 暴露：

/proc/sys/<分类>/<参数>

例如：

cat /proc/sys/net/ipv4/ip_forward
sysctl net.ipv4.ip_forward

这两个命令通常读取同一个内核状态：

net.ipv4.ip_forward = 0

参数名中的点会映射为路径中的斜杠：

net.ipv4.ip_forward
        ↓
/proc/sys/net/ipv4/ip_forward

运行时修改：

sudo sysctl -w net.ipv4.ip_forward=1

等价形式是直接写 procfs：

echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward

sysctl 更适合脚本和运维，因为它会处理参数名、错误信息和批量加载；直接写 /proc/sys 更接近内核接口，但不应假设所有程序都接受完全相同的输入格式。

3. 模块参数

内核模块参数不是普通 sysctl。例如：

ls /sys/module/
cat /sys/module/nf_conntrack/parameters/hashsize

模块参数通常有以下特点：

  • 可能在模块加载时设置；
  • 有些参数支持运行时修改，有些不支持；
  • 即使能写入，也可能只影响后续行为；
  • 模块未加载时，/sys/module/<module>/parameters/ 可能不存在；
  • 持久化方式通常是 /etc/modprobe.d/*.conf，而不是 /etc/sysctl.d/*.conf。

例如：

options nf_conntrack hashsize=262144

这属于模块加载配置，不应写成：

net.nf_conntrack.hashsize = 262144

除非该参数确实以 sysctl 形式暴露。参数的实际接口必须通过当前内核的 /proc、/sys 和文档确认。

4. 资源限制不是 sysctl

文件句柄、进程数等常见问题经常被误归因于 sysctl。

进程资源限制通过 getrlimit(2) / setrlimit(2) 管理，shell 中通常通过：

ulimit -n
ulimit -u

查看。对某个进程可以查看：

cat /proc/<PID>/limits

systemd 服务则常见于：

[Service]
LimitNOFILE=200000
LimitNPROC=65535

因此：

  • fs.file-max 是系统级文件句柄上限相关 sysctl；
  • RLIMIT_NOFILE 是单个进程可打开文件描述符的限制；
  • LimitNOFILE 是 systemd 为服务进程设置 RLIMIT_NOFILE 的方式；
  • 三者不是同一个数，也不会自动互相替代。

一个进程即使拥有很高的 RLIMIT_NOFILE，也可能受到系统可用内存、文件系统、socket 内存和其他内核限制影响。反过来，提高 fs.file-max 也不会自动提高已经启动进程的 RLIMIT_NOFILE。

二、sysctl 的实际数据流：从配置文件到内核状态

运行中的 sysctl 值可以理解为一条数据流：

flowchart LR
    A[内核默认值] --> D[运行时内核状态]
    B[内核启动参数] --> D
    C[sysctl.d 配置文件] --> E[systemd-sysctl 或 sysctl --system]
    E --> D
    F[sysctl -w 或直接写 procfs] --> D
    D --> G[/proc/sys]
    G --> H[应用、网络栈、内存管理、调度器]

关键点是：配置文件不是内核状态本身，而是某个时刻写入内核状态的输入。

执行：

sudo sysctl -w vm.swappiness=10

只改变当前运行内核的值。它不会自动修改任何配置文件，因此重启后可能恢复为内核默认值或发行版配置值。

执行：

sudo sysctl -p /etc/sysctl.conf

通常表示读取指定文件并立即写入。它也不会自动读取所有 /etc/sysctl.d/ 文件。

三、参数来源和优先级：最终值是如何产生的

一个参数的最终值通常经历以下过程：

  1. 内核编译时的默认值；
  2. 内核启动命令行或模块加载参数；
  3. 早期启动程序写入；
  4. systemd-sysctl、传统 sysctl 服务或其他初始化工具加载配置；
  5. 管理员、配置管理工具、容器运行时在系统运行期间修改；
  6. 应用或网络管理组件进一步改变某些相关状态。

并不存在适用于所有发行版、所有参数的单一“优先级表”。尤其需要注意：

  • 某些启动参数优先于运行时设置；
  • 某些参数只能运行时设置；
  • 后写入者可以覆盖先写入者；
  • 某些程序会在启动后自行写入；
  • 容器的网络命名空间可能有独立值；
  • 某些参数在不同内核版本中的默认值不同。

1. 查看当前值和可写性

sysctl net.ipv4.ip_forward
cat /proc/sys/net/ipv4/ip_forward

ls -l /proc/sys/net/ipv4/ip_forward

/proc/sys 中的权限不能简单等同于“普通文件权限”。内核 sysctl handler 可能额外执行范围检查、状态检查和权限检查。

批量查看：

sysctl -a

或：

find /proc/sys -type f -print

sysctl -a 的输出可能很大，且不同发行版、内核配置和模块加载状态会不同。不要把另一台机器的完整输出文件直接当作配置模板。

2. 搜索配置来源

常见位置包括：

/etc/sysctl.conf
/etc/sysctl.d/*.conf
/run/sysctl.d/*.conf
/usr/local/lib/sysctl.d/*.conf
/usr/lib/sysctl.d/*.conf
/lib/sysctl.d/*.conf

但目录和加载规则受发行版及初始化系统影响。可以先检查本机命令和手册：

man sysctl
man sysctl.d
systemctl cat systemd-sysctl.service

在使用 systemd 的系统上，常见加载方式是：

sudo systemctl restart systemd-sysctl

查看服务日志：

journalctl -u systemd-sysctl.service

使用 sysctl --system 时，具体搜索路径和顺序应以本机 man sysctl 为准：

sysctl --system

不要假设执行 sysctl --system 后所有配置项都成功生效。不存在的参数、拼写错误、只读参数和非法值都可能产生错误或警告。

3. 同名文件和加载顺序

sysctl.d 配置通常使用数字前缀控制顺序，例如：

/etc/sysctl.d/50-network.conf
/etc/sysctl.d/99-local.conf

常见实现会按文件名排序加载，后出现的设置覆盖前面的设置。但以下问题仍需核实：

  • 不同目录之间如何合并；
  • 相同文件名是否由更高优先级目录覆盖；
  • 本机的 systemd-sysctl 版本如何定义路径；
  • 其他启动脚本是否在之后再次写入。

因此，一个可靠的排查方式不是只搜索 /etc/sysctl.conf，而是同时检查：

grep -R --line-number --no-messages \
  -E 'net\.ipv4\.ip_forward|vm\.swappiness' \
  /etc/sysctl.conf /etc/sysctl.d /run/sysctl.d \
  /usr/local/lib/sysctl.d /usr/lib/sysctl.d /lib/sysctl.d

然后观察最终值：

sysctl net.ipv4.ip_forward vm.swappiness

四、类型、单位和语义：数字不等于含义

sysctl 常见值类型包括：

  • 布尔值，通常表示为 0 或 1；
  • 整数或无符号整数；
  • 时间，可能以毫秒、秒或 jiffies 表示；
  • 字节数；
  • 位掩码；
  • 由多个整数构成的复合值；
  • 逗号或空格分隔的列表。

不能仅凭参数名猜测单位。例如某个参数名包含 time，不意味着它一定使用秒。必须查看当前内核文档、源码或对应的 man page。

1. 复合参数示例

某些网络参数是多个数值：

sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem

典型输出类似：

net.ipv4.tcp_rmem = 4096 131072 6291456

这类值通常表示最小值、默认值和最大值，但具体语义由参数实现定义，不能把所有三元组都套用同一个解释。

修改时应保留格式：

sudo sysctl -w net.ipv4.tcp_rmem='4096 131072 16777216'

错误做法是只设置一个数字：

sudo sysctl -w net.ipv4.tcp_rmem=16777216

因为这可能被拒绝，也可能改变为不符合预期的格式。

2. 约束关系

很多参数存在内部约束。例如一个最小值、默认值、最大值的三元组通常要求：

min≤default≤maxmin \le default \le max

如果设置：

100 50 1000

即使解析器接受，也可能违反语义，或被内核拒绝。

参数之间还可能有更高层约束。例如 socket 接收缓冲区的实际大小不只由 net.core.rmem_max 决定，还会受到：

  • 协议族或协议实现；
  • socket 选项；
  • 自动调优逻辑；
  • 内存压力；
  • cgroup 约束；
  • 应用自身设置；
  • 内核版本实现。

因此“把最大值调大”不等于“每条连接都会使用这个值”。

五、持久化：怎样让修改跨越重启

1. 临时验证

适合单次实验：

old_value=$(sysctl -n net.ipv4.ip_forward)
sudo sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

验证完成后恢复：

sudo sysctl -w net.ipv4.ip_forward="$old_value"

这种方式的优点是影响范围清楚、回滚简单；缺点是重启后失效。

2. 使用独立配置文件

建议为明确的变更创建独立文件，例如：

sudo tee /etc/sysctl.d/60-wr-tuning.conf >/dev/null <<'EOF'
# 仅示例：允许 IPv4 转发
net.ipv4.ip_forward = 1
EOF

检查语法并加载：

sudo sysctl --system
sysctl net.ipv4.ip_forward

这里的 60- 只是一个排序示例，不代表所有系统都必须使用这个数字。文件名应表达管理意图，避免直接覆盖发行版文件。

3. 配置文件不等于当前状态

假设配置文件中有：

vm.swappiness = 10

但当前查询结果仍是：

vm.swappiness = 60

可能原因包括：

  • 文件没有被加载；
  • 文件路径不在当前加载器搜索范围；
  • 后续文件覆盖了它；
  • 参数名拼写错误；
  • 该参数在启动后被其他服务再次修改；
  • 运行在容器或不同的网络命名空间中；
  • 写入失败但只注意到了部分输出。

可以分开验证：

grep -R --line-number 'vm.swappiness' /etc/sysctl.conf /etc/sysctl.d 2>/dev/null
sudo sysctl -w vm.swappiness=10
sysctl vm.swappiness
sudo systemctl restart systemd-sysctl
sysctl vm.swappiness
journalctl -u systemd-sysctl.service -b

4. 让 systemd 服务获得资源限制

如果问题是服务进程的文件描述符上限，应该使用服务单元配置，而不是只改 sysctl：

sudo systemctl edit myapp.service

写入：

[Service]
LimitNOFILE=200000

然后：

sudo systemctl daemon-reload
sudo systemctl restart myapp.service
cat /proc/$(systemctl show -p MainPID --value myapp.service)/limits | grep -i 'open files'

必须重启服务，因为已经运行的进程不会因为修改 unit 文件而自动改变其 RLIMIT_NOFILE。

六、命名空间：为什么不同环境看到的值可能不同

Linux 命名空间会隔离部分内核状态。网络命名空间尤其重要：

readlink /proc/1/ns/net
readlink /proc/<PID>/ns/net

如果两个进程的网络命名空间不同，它们看到的部分网络 sysctl 可能不同，例如接口级、IPv4 路由相关或协议栈相关参数。

但并非所有 sysctl 都是网络命名空间独立的。某些参数是：

  • 全局的；
  • user namespace 相关；
  • cgroup 相关；
  • per-network-namespace；
  • per-interface；
  • 只在初始命名空间可修改。

容器内执行：

sysctl net.ipv4.ip_forward

不一定代表宿主机的同名值。容器运行时还可能限制：

  • 是否允许容器设置该参数；
  • 是否授予 CAP_NET_ADMIN；
  • 是否允许访问 /proc/sys；
  • 是否使用宿主机网络命名空间；
  • 是否由 Kubernetes 的 safe/unsafe sysctl 策略过滤。

排查时应记录命名空间和权限：

id
capsh --print 2>/dev/null | grep -E 'Current|cap_net_admin'
readlink /proc/self/ns/net
sysctl net.ipv4.ip_forward

“容器内 sysctl 修改成功”与“宿主机全局状态改变”不能画等号。

七、网络调优中的典型误区：Buffer、Backlog、Port 和 Conntrack

网络参数最容易被组合成“万能调优模板”，但它们处于不同的数据路径。

1. Socket Buffer：容量、窗口和实际使用量

接收路径可以简化为：

网卡 → 驱动队列 → softirq/NAPI → TCP 接收队列 → socket 接收缓冲区 → 应用 read()

发送路径则大致为：

应用 write() → socket 发送缓冲区 → TCP 拥塞控制 → qdisc/设备队列 → 网卡

相关参数可能包括：

sysctl net.core.rmem_default
sysctl net.core.rmem_max
sysctl net.core.wmem_default
sysctl net.core.wmem_max
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem

它们分别涉及默认值、最大值和 TCP 自动调优范围，但不表示每个 socket 都会立即分配最大内存。

一个简单估算可以说明容量与吞吐、延迟的关系。若链路带宽为 BB bit/s，往返时间为 RTTRTT 秒，则带宽时延积为：

BDP=B×RTT8BDP = \frac{B \times RTT}{8}

例如：

  • 带宽 B=1 Gbit/sB = 1\text{ Gbit/s}；
  • RTT =100 ms=0.1 s= 100\text{ ms}=0.1\text{ s}。

则：

BDP=1,000,000,000×0.18=12,500,000 bytes≈11.9 MiBBDP = \frac{1{,}000{,}000{,}000 \times 0.1}{8} = 12{,}500{,}000\text{ bytes} \approx 11.9\text{ MiB}

这表示要在该 RTT 下填满 1 Gbit/s 链路，端到端在途数据量可能需要约 12.5 MB。它不等于必须把每个 socket 缓冲区设为 12.5 MB，因为还存在：

  • TCP 接收窗口和发送窗口；
  • 拥塞控制；
  • 内核 socket bookkeeping；
  • 应用读写速度；
  • 多连接共享内存；
  • 丢包和重传；
  • 接收端处理能力。

如果有 NN 条连接，每条连接实际占用 SS 字节，仅粗略估计 socket 数据相关内存就可能达到：

M≈N×SM \approx N \times S

例如 N=50,000N=50{,}000，每条连接平均 256 KiB：

M=50,000×262,144≈12.5 GiBM = 50{,}000 \times 262{,}144 \approx 12.5\text{ GiB}

这还没有包括 socket 对象、TCP 状态、slab、conntrack、TLS、应用对象和 page cache。因此将最大 buffer 从几 MB 盲目提高到几十或几百 MB，可能在高并发下制造内存压力。

2. Backlog：不同队列不是同一个参数

至少要区分两个概念。

SYN backlog

监听 socket 收到 SYN 后，连接尚未完成三次握手时，会经过半连接相关队列。常见参数：

sysctl net.ipv4.tcp_max_syn_backlog

它主要影响监听端处理半连接的容量，但实际行为还涉及 SYN cookies、内存压力、监听 socket 和内核版本。

accept backlog

握手完成后，连接等待应用调用 accept()，常见上限相关参数：

sysctl net.core.somaxconn

应用调用：

listen(fd, backlog);

传入的 backlog 也参与决定队列上限。实际上限不能简单写成某一个参数值，通常可以抽象为：

Qeffective≤min⁡(Qapplication,Qkernel)Q_{\text{effective}} \le \min(Q_{\text{application}}, Q_{\text{kernel}})

具体上限和截断规则由内核版本及协议实现决定。

因此，增加 tcp_max_syn_backlog 不一定解决应用 accept() 太慢的问题；增加 somaxconn 也不能修复 CPU 饱和、事件循环阻塞或应用线程池耗尽。

观察监听队列：

ss -lnt

输出中的 Recv-Q 和 Send-Q 对监听 socket 的含义与已建立连接不同。监听 socket 的队列是否持续增长，应结合应用 accept 延迟、SYN 丢包、重传和连接建立错误一起判断。

3. Port：端口范围不是连接容量

查看临时端口范围：

sysctl net.ipv4.ip_local_port_range

典型形式：

net.ipv4.ip_local_port_range = 32768 60999

可用端口数量按闭区间计算：

P=high−low+1P = high - low + 1

对上述范围：

P=60999−32768+1=28232P = 60999 - 32768 + 1 = 28232

这不是机器最多能建立的 TCP 连接数。连接的唯一性由本地地址、本地端口、远端地址、远端端口和协议共同决定：

(local IP,local port,remote IP,remote port,protocol)(local\ IP, local\ port, remote\ IP, remote\ port, protocol)

但是，当单个客户端使用一个本地 IP 连接同一个远端 IP 和端口时，临时端口范围会成为明显约束。压测工具出现：

Cannot assign requested address

可能是临时端口耗尽，也可能是源地址、路由、TIME_WAIT、策略路由或其他资源问题。

修改范围：

sudo sysctl -w net.ipv4.ip_local_port_range='20000 65000'

风险包括：

  • 与固定服务端口冲突；
  • 与防火墙、NAT、策略路由假设不一致；
  • 不能解决单进程文件描述符限制；
  • 不能解决目标端连接限制；
  • 不能消除 TIME_WAIT 的协议语义；
  • 在存在多个地址和 NAT 时，实际瓶颈可能在别处。

4. Conntrack：状态表不是 socket backlog

连接跟踪通常由 netfilter conntrack 使用。查看相关参数：

sysctl net.netfilter.nf_conntrack_max 2>/dev/null
cat /proc/sys/net/netfilter/nf_conntrack_count 2>/dev/null

粗略利用率可计算为：

U=countmaxU = \frac{count}{max}

例如：

count = 180000
max = 200000

则：

U=0.9U = 0.9

接近上限时，新连接或相关流量可能因为无法创建 conntrack 项而失败。日志中可能看到类似：

nf_conntrack: table full, dropping packet

但提高 nf_conntrack_max 会增加内存消耗。conntrack 项还可能与 NAT、超时、协议状态有关，不能仅凭 count/max 判断业务容量。

诊断时结合：

conntrack -S 2>/dev/null
dmesg -T | grep -i conntrack
ss -s
nstat -az

“连接数很多”可能发生在四个不同位置：

  1. 应用 accept 队列；
  2. TCP 半连接队列；
  3. 已建立 socket；
  4. conntrack 状态表。

这些位置的故障表现和修复方法不同。

八、运行时修改的风险：从“能写”到“会产生什么后果”

1. 内存参数的风险

例如：

sysctl vm.swappiness
sysctl vm.overcommit_memory
sysctl vm.overcommit_ratio

这些参数影响全局内存管理行为。修改 vm.swappiness 并不是“关闭 swap”；它改变的是内核在回收匿名页和文件页时的倾向。真正的行为还取决于：

  • 是否启用了 swap；
  • 内存压力；
  • cgroup memory limit；
  • 工作集是否可回收；
  • page cache 访问模式；
  • 内核版本的回收实现。

vm.overcommit_memory 则影响内存承诺策略，错误设置可能导致：

  • malloc() 行为与预期不同；
  • 进程在后续触碰页面时失败；
  • OOM 风险改变；
  • 数据库或大型服务启动行为变化。

这类参数不能仅通过“压测吞吐提高”判断正确性，还要检查 OOM、major fault、swap in/out 和尾延迟。

2. 安全参数的风险

例如：

sysctl kernel.randomize_va_space
sysctl kernel.kptr_restrict
sysctl kernel.dmesg_restrict
sysctl net.ipv4.conf.all.rp_filter

它们可能影响地址随机化、内核地址信息暴露、内核日志访问和源地址校验。为了排查或压测而关闭安全机制，必须明确：

  • 修改影响的是哪个命名空间或整台机器；
  • 是否需要重启服务；
  • 是否违反安全基线；
  • 恢复动作是什么；
  • 是否有审计记录。

性能优化不能把安全参数当作无成本旋钮。

3. TCP 行为参数的风险

例如：

sysctl net.ipv4.tcp_syncookies
sysctl net.ipv4.tcp_tw_reuse
sysctl net.ipv4.tcp_fin_timeout

这些参数涉及连接建立、关闭和 TIME_WAIT 状态。

常见误解是把 tcp_fin_timeout 当成“TIME_WAIT 生命周期”。它主要关联特定 TCP 关闭状态的超时行为，不能简单等同于所有 TIME_WAIT 连接的存活时间。

同样，tcp_tw_reuse 不是“安全地删除 TIME_WAIT”。它改变特定条件下主动连接复用行为，必须结合 NAT、时间戳、旧报文和内核版本语义判断。不要使用过时教程中的 tcp_tw_recycle；该参数已从现代内核中移除，相关旧建议不应直接套用。

4. 整数溢出和单位错误

在配置自动化中，最危险的错误之一是单位误判：

timeout = 60000

可能被理解为 60000 秒，也可能是 60000 毫秒，还可能是内核内部单位。另一个错误是把 32 位整数范围内的参数设置成超大数，导致拒绝、截断或意外行为。

正式变更前至少应确认：

sysctl -a 2>/dev/null | grep '^net\.'
man 7 tcp
man 5 sysctl.d

如果文档没有说明单位，应查看对应内核文档或源码，而不是根据名称猜测。

九、压测：怎样证明参数改变了目标，而不是改变了噪声

压测的目标不是证明“某个参数越大越好”，而是验证一个可证伪的假设。

一个完整实验至少包含：

假设→单变量变更→可观测指标→重复实验→回滚验证\text{假设} \rightarrow \text{单变量变更} \rightarrow \text{可观测指标} \rightarrow \text{重复实验} \rightarrow \text{回滚验证}

1. 先记录基线

示例：

mkdir -p /var/tmp/sysctl-test/before

sysctl net.core.somaxconn \
       net.ipv4.tcp_max_syn_backlog \
       net.ipv4.ip_local_port_range \
       net.ipv4.tcp_rmem \
       net.ipv4.tcp_wmem \
       > /var/tmp/sysctl-test/before/sysctl.txt

ss -s > /var/tmp/sysctl-test/before/ss.txt
free -h > /var/tmp/sysctl-test/before/memory.txt
vmstat 1 5 > /var/tmp/sysctl-test/before/vmstat.txt
nstat -az > /var/tmp/sysctl-test/before/nstat.txt

对于网络服务，还应记录：

sar -n DEV,TCP,ETCP 1 5 2>/dev/null
cat /proc/net/sockstat
cat /proc/net/sockstat6

若使用 conntrack：

cat /proc/sys/net/netfilter/nf_conntrack_count 2>/dev/null
cat /proc/sys/net/netfilter/nf_conntrack_max 2>/dev/null

基线必须包含业务指标，例如：

  • 吞吐；
  • 请求成功率；
  • P50、P95、P99 延迟；
  • 建连失败；
  • 重传；
  • CPU 利用率和软中断；
  • 内存、swap、OOM；
  • dropped packets；
  • 文件描述符使用量。

只测吞吐而不测错误率和尾延迟，可能把“更多请求被排队或丢弃”误判为性能提升。

2. 一次只改变一个主要变量

例如验证 accept 队列：

old_somaxconn=$(sysctl -n net.core.somaxconn)
old_syn_backlog=$(sysctl -n net.ipv4.tcp_max_syn_backlog)

sudo sysctl -w net.core.somaxconn=4096

如果同时改：

somaxconn
tcp_max_syn_backlog
ip_local_port_range
tcp_tw_reuse
rmem/wmem

即使结果发生变化，也无法知道是哪一个因素起作用。

实验结束后恢复：

sudo sysctl -w net.core.somaxconn="$old_somaxconn"
sudo sysctl -w net.ipv4.tcp_max_syn_backlog="$old_syn_backlog"

需要注意，某些参数对新建 socket 或新连接更明显，某些参数对已有连接也可能产生影响。测试前应明确是否要重启服务、清空连接、等待连接自然结束，以及这些动作本身是否改变了实验条件。

3. 解释一个 backlog 实验

假设应用执行：

listen(fd, 1024);

当前：

net.core.somaxconn = 128

即使应用请求 1024，实际 accept 队列也可能被内核限制到不超过 128 的范围。将 somaxconn 改为 4096 后，应用请求仍然是 1024，因此有效队列不会自动变成 4096。

可抽象为：

Qeffective≤min⁡(1024,4096)=1024Q_{\text{effective}} \le \min(1024, 4096)=1024

如果应用改为：

listen(fd, 8192);

则：

Qeffective≤min⁡(8192,4096)=4096Q_{\text{effective}} \le \min(8192, 4096)=4096

但这只是容量上限推导，不代表应用能以相同速度处理连接。若应用线程调度、TLS 握手、认证或后端连接池成为瓶颈，队列变大可能只是延迟了失败。

4. 负载应覆盖故障边界

网络服务至少应分别测试：

  • 长连接与短连接；
  • 高并发连接建立；
  • 单连接高吞吐；
  • 多连接低吞吐；
  • 正常请求和后端变慢；
  • 客户端主动关闭与服务端主动关闭；
  • 丢包或高 RTT；
  • 服务重启、滚动发布和连接排空。

例如只测试长连接吞吐，无法验证临时端口耗尽、SYN backlog 和 TIME_WAIT 相关问题；只测试本机回环，也无法代表真实网卡、MTU、路由和 conntrack 路径。

5. 观察内核计数器而非只看应用日志

压测过程中可以持续观察：

watch -n 1 '
echo "=== sysctl ==="
sysctl net.core.somaxconn net.ipv4.tcp_max_syn_backlog
echo "=== sockets ==="
ss -s
echo "=== sockstat ==="
cat /proc/net/sockstat
echo "=== memory ==="
free -h
'

另开终端观察：

nstat -az
dmesg -Tw

如果使用 perf：

sudo perf stat -a -e \
  context-switches,cpu-migrations,page-faults,cycles,instructions \
  -- sleep 30

命令是否可用、事件是否受权限限制，取决于发行版内核配置和 perf 权限策略。

判断因果关系时，应该比较：

同一版本应用
同一流量模型
同一机器和网络
同一预热时间
同一测量窗口
仅改变一个参数
重复多个样本

如果只进行一次“改参数前/改参数后”比较，结果可能被缓存、连接复用、JIT 预热、邻居流量或频率调节影响。

十、验证：确认“写入成功”和“行为生效”是两件事

1. 语法和当前值验证

sudo sysctl -w net.core.somaxconn=4096
sysctl net.core.somaxconn

如果输出：

net.core.somaxconn = 4096

只能说明当前 sysctl 值是 4096。它不证明：

  • 应用已经重新调用 listen()；
  • 应用传入的 backlog 足够大；
  • 连接请求已进入该队列；
  • 监听 socket 使用了期望的网络命名空间；
  • 业务延迟改善。

2. 进程和 socket 验证

查找监听 socket：

ss -lntp

验证具体进程：

pid=$(pidof myapp)
cat /proc/"$pid"/limits
readlink /proc/"$pid"/ns/net

检查应用启动命令、配置和实际监听端口：

systemctl status myapp.service
systemctl show myapp.service -p ExecStart -p LimitNOFILE

3. 从故障计数器验证

连接队列问题可结合：

nstat -az | grep -Ei 'Listen|Retrans|TCP'
ss -s

文件描述符问题可结合：

cat /proc/sys/fs/file-nr
cat /proc/sys/fs/file-max
ls /proc/"$pid"/fd | wc -l
cat /proc/"$pid"/limits | grep -i 'open files'

file-nr 的字段含义受内核版本影响，不能只把第一个数字机械地解释成“当前打开文件数”。应结合 /proc/<PID>/fd、服务限制和应用错误日志判断。

内存问题可结合：

grep -E 'MemAvailable|SwapFree|Dirty|Slab|SReclaimable' /proc/meminfo
vmstat 1

如果发生 OOM：

journalctl -k | grep -i -E 'oom|out of memory|killed process'

十一、回滚：把恢复设计成变更的一部分

1. 立即回滚

最简单的方式是记录旧值：

param=net.core.somaxconn
old=$(sysctl -n "$param")

sudo sysctl -w "$param=4096"

# 实验完成
sudo sysctl -w "$param=$old"

多个参数应保存为可执行的恢复文件：

backup=/var/tmp/sysctl-rollback-$(date +%Y%m%d-%H%M%S).conf

for p in \
  net.core.somaxconn \
  net.ipv4.tcp_max_syn_backlog \
  net.ipv4.ip_local_port_range
do
  printf '%s = %s\n' "$p" "$(sysctl -n "$p")"
done | tee "$backup"

恢复：

sudo sysctl -p "$backup"

这要求备份文件格式正确，并且参数仍存在。恢复前应检查：

test -r "$backup"
grep -Ev '^[[:space:]]*(#|$)' "$backup"

2. 回滚持久化配置

如果添加了：

/etc/sysctl.d/60-wr-tuning.conf

回滚不仅要恢复当前值，还要删除或禁用该文件：

sudo mv /etc/sysctl.d/60-wr-tuning.conf \
        /etc/sysctl.d/60-wr-tuning.conf.disabled

sudo sysctl --system

否则下一次重启或 systemd-sysctl 执行时，问题可能再次出现。

对于版本控制管理的配置，不建议直接删除审计记录；可以提交反向变更，并保留原始变更、实验结果和回滚原因。

3. 重启后的回滚

如果参数通过引导加载器设置，运行时恢复并不够。必须同时恢复引导配置。例如检查：

cat /proc/cmdline

确认启动参数是否仍存在。若修改了 GRUB 配置，应按本发行版方式重新生成配置，并在重启前验证生成结果。

远程机器尤其要预先准备：

  • 带外管理或控制台；
  • 第二个 SSH 会话；
  • 自动回滚计时器；
  • 云平台快照或可替换实例；
  • 明确的恢复命令；
  • 变更窗口和连接排空方案。

4. 自动回滚的思路

对于有风险的运行时实验，可以使用延迟确认：

backup=/var/tmp/sysctl-rollback.conf
sysctl net.core.somaxconn > "$backup"

sudo sysctl -w net.core.somaxconn=4096

echo "实验通过后删除 $backup；否则执行 sudo sysctl -p $backup"

更严格的自动化系统应使用：

  1. 写入前保存旧值；
  2. 应用新值；
  3. 运行健康检查；
  4. 在超时前收到人工确认；
  5. 未确认则恢复；
  6. 恢复后再次验证。

不要把“SSH 连接仍然存在”当作健康检查。网络参数可能导致新连接失败，而已有 SSH 会话仍然正常。

十二、常见失败表现及其真正含义

“sysctl: cannot stat ...”

通常表示：

  • 参数不存在；
  • 内核未启用相关功能；
  • 模块未加载；
  • 参数名称来自其他版本；
  • 当前容器隐藏了该接口。

不要用创建普通文件的方式“补出”这个参数。/proc/sys 中的条目由内核注册，普通文件不能替代内核参数。

“permission denied”

可能原因包括：

  • 没有 root 权限；
  • 缺少容器所需 capability；
  • sysctl 被命名空间或安全策略限制；
  • 参数本身只读；
  • 当前内核状态不允许修改。

以 root 运行也不保证所有参数都可写。

“改完重启又恢复”

这通常说明只做了运行时修改，或者持久化文件没有被加载。应检查：

cat /proc/cmdline
sysctl net.ipv4.ip_forward
systemctl is-enabled systemd-sysctl.service
journalctl -u systemd-sysctl.service -b

还要搜索所有可能的配置文件和启动脚本。

“参数变了，但性能没变”

这可能是正常结果，因为瓶颈不在该参数对应的数据路径。例如：

  • 增大 backlog，但应用 accept 速率不变；
  • 增大 socket buffer，但带宽或拥塞窗口受限；
  • 增大端口范围，但服务端或 NAT 端口耗尽；
  • 增大 conntrack 上限，但 CPU 或内存已经饱和；
  • 提高 LimitNOFILE，但应用自身连接池仍有更小上限。

参数写入只是必要条件之一，不是因果证明。

“性能提高，但故障率也提高”

常见原因是：

  • 队列更大导致排队延迟上升；
  • 更大的 buffer 增加内存占用；
  • 更高的并发放大后端压力；
  • 超时被延后，最终形成级联失败；
  • 丢包、重传和连接状态表占用增加；
  • 安全校验被弱化。

因此压测必须同时观察成功率、尾延迟、资源峰值和恢复能力。

十三、生产变更的最小闭环

一个可审计的 sysctl 变更应至少包含以下信息：

参数：
当前值：
目标值：
参数作用：
所在数据路径：
预期改善：
潜在副作用：
影响范围：
验证指标：
回滚值：
持久化位置：
变更时间：
执行人：

实际执行可以按以下顺序：

# 1. 记录身份、内核和当前值
uname -a
cat /proc/cmdline
sysctl net.core.somaxconn
sysctl net.ipv4.tcp_max_syn_backlog

# 2. 保存回滚值
sudo sysctl net.core.somaxconn \
  net.ipv4.tcp_max_syn_backlog \
  > /var/tmp/sysctl-rollback.conf

# 3. 临时修改
sudo sysctl -w net.core.somaxconn=4096
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=4096

# 4. 立即验证
sysctl net.core.somaxconn net.ipv4.tcp_max_syn_backlog

# 5. 执行固定流量模型的压测
# 6. 比较业务指标和内核计数器
# 7. 通过后再写入版本控制的 sysctl.d 文件
# 8. 失败则恢复
sudo sysctl -p /var/tmp/sysctl-rollback.conf

如果实验结论是“目标参数不是瓶颈”，也应回滚而不是把实验值留在机器上。否则后续故障排查会面对一个未经确认的额外变量。

十四、结论：把 sysctl 当作内核接口，而不是数字字典

sysctl 的本质是用户空间对内核运行时状态的一组受控接口。正确使用它需要同时回答四个问题：

  1. 来源：这个值来自内核默认值、启动参数、sysctl.d、模块参数、容器运行时，还是应用自身？
  2. 语义：它修改的是哪个组件、哪个队列、哪个命名空间、哪个时间或内存单位？
  3. 效果：它是否真正影响了目标数据路径，还是只是改变了一个与瓶颈无关的上限？
  4. 生命周期：修改是否只对当前运行有效，是否需要重启服务，如何持久化，如何回滚？

尤其在网络调优中，Socket Buffer、Backlog、临时 Port 和 Conntrack 分别对应不同状态和故障路径；在资源限制中，sysctl、RLIMIT 和 systemd Limit* 也分别属于不同层次。只有先定位状态，再用可重复的单变量压测验证，最后保留明确的回滚路径，内核参数调整才是工程变更，而不是经验数字的堆叠。

系列导航与关联阅读

官方资料

本文依据 Linux 内核、systemd 与主流发行版官方文档重新梳理；正文与实验由 WR BLOG 编写。