操作系统内功 · 第 43 篇｜sysctl 调优：/proc/sys 的高频参数与实战

每个工程师都见过那种「Linux 生产环境调优脚本」：几十行 sysctl -w 一把梭，配上「连接数提升 10 倍」的标题。抄过的人里，能说清其中三分之一参数含义的都算少数——更常见的结局是：参数改了，故障换了形态（somaxconn 调大了，应用代码的 backlog 没改，什么都没变），或者参数之间互相拆台（tcp_tw_recycle 的年代里，NAT 环境开它直接丢包，这个参数在 4.12 内核被移除，正是因为它伤害的人比受益的人多）。这一篇不讲「参数大全」，讲三件事：sysctl 机制本身（参数树怎么组织、怎么持久化、改了什么立即生效）、四组高频参数的真实语义与合理取值的推导过程（授人以渔）、以及容器场景里「哪些参数可改、哪些改了也白改」的 namespace 边界。目标是下次拿到一份调优清单，你能自己判断每一行的对错。

一、sysctl 机制：参数树与持久化链

内核所有可调参数以一棵树的形式暴露在 /proc/sys 下，顶级目录按子系统分组：net/（网络栈）、vm/（内存管理）、fs/（文件系统与句柄）、kernel/（进程与内核杂项）、dev/（设备）。读写这两个入口完全等价：sysctl -w net.core.somaxconn=4096 与 echo 4096 > /proc/sys/net/core/somaxconn 效果相同（后者在嵌入式容器里更常用）。写操作立即生效、立即全系统生效，不需要重启任何服务——这是理解「改参数」与「改配置」区别的关键：sysctl -w 是改当前内核的运行时状态，重启后丢失；持久化要落到 /etc/sysctl.conf 或 /etc/sysctl.d/*.conf，由 systemd-sysctl 服务在启动时加载：

$ cat /etc/sysctl.d/99-app.conf
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 16384
vm.swappiness = 1
$ sudo sysctl --system          # 按优先级重新加载所有配置文件
$ sysctl net.core.somaxconn      # 验证生效
net.core.somaxconn = 4096

三个机制细节常被忽略。其一，加载顺序是文件名字典序，/etc/sysctl.d/99-*.conf 最后加载、可以覆盖更早的（发行版自身配置在 10-system.conf 等位置，用户自定义习惯放 99-）；同名参数后写的赢。其二，sysctl --system 与 sysctl -p 不同：前者加载全部 sysctl.d 目录树（含 /run、/usr/local/lib 等），后者只读 /etc/sysctl.conf。其三，参数有权限边界：写 /proc/sys 需要 root（准确说是 CAP_SYS_ADMIN），且部分参数是只读的（如 kernel.random.uuid），还有一类参数在容器里不可写——下一节细讲。

flowchart TD
    A["/proc/sys 参数树"] --> B["net/ 网络栈<br/>多数参数挂 network namespace<br/>（容器可独立设置）"]
    A --> C["vm/ 内存管理<br/>全局生效（swappiness、overcommit、dirty）"]
    A --> D["fs/ 文件句柄与文件系统<br/>全局生效（file-max、nr_open）"]
    A --> E["kernel/ 进程与内核杂项<br/>pid_max、panic、sysrq"]
    B --> F["netns 级：容器内可改<br/>somaxconn 5.4前全局 / port_range 每 netns"]
    C --> G["主机级：容器里改不动或改的是宿主机<br/>应在节点层统一配置"]
    D --> G

二、TCP 连接三件套：somaxconn、syn_backlog 与 port_range

somaxconn（net.core.somaxconn）是 listen backlog 的内核上限。完整链路是：应用代码 listen(fd, backlog) 请求一个挂起连接队列长度 → 内核取 min(backlog, somaxconn) 作为实际值 → 超过 backlog 的连接在 SYN 阶段被丢弃或拒绝（受 tcp_abort_on_overflow 影响，默认静默丢弃——客户端表现为连接超时而非拒绝，这是「看起来像网络问题」的假象来源）。老内核（≤5.3 之前的主流发行版）默认 somaxconn=128，对突发并发（如发布后瞬时回连、秒杀流量）远远不够，队列溢出的直接证据是 netstat -s | grep -i listen 的 times the listen queue of a socket overflowed——这个计数器非零就说明发生过溢出，调大 somaxconn 与应用 backlog 是对症药。注意必须两边同时改：内核上限（sysctl）与应用请求值（nginx 的 listen backlog=、Java 的 ServerSocket 构造参数、Go 的 ListenConfig.Backlog）取的是 min，只改一边等于没改。新内核（5.4+）默认已提到 4096，但老系统升级清单里它仍然排第一位。

tcp_max_syn_backlog（默认常见 1024/2048）是 SYN 半连接队列的上限，防御 SYN Flood 的第一道堤坝，与 somaxconn 协同（实际生效值还有随 backlog 动态放大的算法，内核会按 min(somaxconn, backlog) 的倍数关系调整）。ip_local_port_range（默认 32768 60999）是主动外连的临时端口池：28232 个端口，每个主动出站连接占一个，TIME_WAIT 状态下端口要等 60 秒才能复用——推导一下这个数字的分量：对同一个目标 ip:port，本机出站连接的理论上限是 28232 / 60s ≈ 470 QPS。压测过代理服务、爬虫、短信网关的人都会在这里撞墙，典型报错是 Cannot assign requested address（connect 时 EADDRINUSE 的出站版本）。解法按序：扩池（net.ipv4.ip_local_port_range = 1024 65535，扩到约 6.4 万，上限翻倍）、开 tcp_tw_reuse（默认已为 1，对主动外连方向按时间戳安全复用 TIME_WAIT 端口——注意它只帮出站方向，帮不了入站）、以及治本：连接复用（连接池/长连接，让 470 QPS 的限制失去意义）。这组参数的教学意义在于：每个「合理取值」背后都有一条可以从默认值推导出的硬约束，不推导就调参，容易把症状挪个位置。

三、文件句柄与内存三参数：file-max、overcommit 与 dirty

文件句柄层级在 fd 那一篇讲过三层（ulimit -n / nr_open / file-max），sysctl 侧对应后两者：fs.file-max 是全系统 fd 总量上限（新内核默认 LONG_MAX 级别，几乎不用动），fs.nr_open 是单进程硬上限（默认 1048576，ulimit -n 的天花板）——单机百万连接的网关必须先抬 nr_open，否则 ulimit -n 拉不上去，这是长连接服务清单里与 somaxconn 并列的必改项。验证工具是 cat /proc/sys/fs/file-nr（已分配数 / 空闲数 / 上限），第一列接近第三列就是句柄耗尽前兆。

内存侧的三个参数误用率最高。vm.swappiness 的语义在 swap 一篇已详述（回收配比而非 swap 开关），这里只补一句清单纪律：见清单上写 vm.swappiness=0 就要警惕——0 的语义（3.5+）是「尽量不换出」而非「禁止换出」，且会让 kswapd 在匿名页占优时陷入空转，想「几乎不用」应设 1。vm.overcommit_memory 是内存分配策略的开关，三个值的语义必须在看清边界的前提下选：0（默认，启发式——允许明显过度的申请，靠 OOM Killer 兜底）；1（来者不拒，malloc 永远成功，malloc 大内存 + 实际少用的程序如某些 JVM、大页应用需要它，因为它们申请时不写满）；2（严格模式，拒绝超过「swap + RAM×overcommit_ratio」的申请，Redis 官方文档明确建议数据库类服务配 overcommit_memory=2 + 合理 ratio，理由是把「申请即承诺」变成硬约束，把故障从运行期 OOM 提前到分配期报错——故障定位成本大幅下降）。Redis 启动日志里的那句 WARNING overcommit_memory is set to 0 就是这个建议的出处。vm.dirty_ratio / dirty_background_ratio（脏页写回阈值，默认 20/10 的百分比）在脏页回写一篇讲过机制，清单角度的提醒是：大内存机器上 20% 的百分比意味着巨大的绝对值（256GB 机器 = 51GB 允许脏页），崩溃时丢失的窗口与回写风暴的规模都随之放大，按绝对字节配比（dirty_bytes 系列）更适合大内存机器。

四、容器里的 sysctl：namespace 边界与白名单

容器是 sysctl 实践中最容易翻车的场景，核心是参数的 namespace 隶属决定「能不能改、改给谁」。net.* 子树的绝大多数参数挂在 network namespace 上——每个容器（每个 netns）有独立副本，docker run --sysctl net.ipv4.ip_local_port_range=1024 65535 或 K8s 的 podSecurityContext.sysctls 都能安全地按容器设置。vm.* 与 fs.* 大部分是全局的（挂在初始 namespace）：容器里改 vm.swappiness 改的是整台宿主机的参数（如果容器有特权），无特权的容器则直接被拒。这是「容器里调参不生效」的根源——你以为在调容器，实际在调主机或者什么都没调到。运行时的白名单机制把这个边界写死：Docker 默认允许的 unsafe sysctl 白名单基本只有 kernel.msg* 与 net.* 中标为 namespace 化的子集（net.ipv4.ip_local_port_range、net.ipv4.tcp_* 的大多数、net.ipv4.ping_group_range 等）；K8s 默认 safe sysctl 白名单更窄（只有 kernel.shm_rmid_forced、net.ipv4.ip_local_port_range 等少数几个），其余要管理员在 kubelet 的 --allowed-unsafe-sysctls 里显式放行。验证某个参数是否 namespace 化的实操方法：

# 宿主机与容器内各读一次，值不同即 namespace 化
$ cat /proc/sys/net/ipv4/ip_local_port_range     # 宿主机
1024 65535
$ docker run --rm alpine cat /proc/sys/net/ipv4/ip_local_port_range
32768 60999                                       # 容器内有独立副本

容器场景的清单纪律由此而来：主机级参数（vm.、fs.）在节点层统一配置、 DaemonSet 或运维流程落地；netns 级参数（net.*）按 Pod/容器配置；试图在容器里改主机参数的清单条目，要么搬回节点层，要么标记为不可执行。K8s 集群里还要注意：Pod sysctls 配置在 PodSecurityContext 上，但受 admission（PSA/PSP 时代策略）与节点白名单双重过滤，上线前要验证实际生效（进容器 cat 对应 procfs 路径），别只看 YAML。

五、验证方法论：基线、单变量与回滚

调参不是改完就结束，没有验证的调参等于盲改。一套最小流程：第一步，测基线——改参数前记录现状，性能类用真实压测（wrk/jmeter 打出 P99/吞吐曲线），资源类抓 counters（netstat -s | grep -i overflow、vmstat 的 si/so、cat /proc/net/sockstat 的 tcp 内存页），没有基线的「提升 10 倍」无法证伪。第二步，单变量——一次只改一个参数组（比如只动 somaxconn + 应用 backlog），压测对比，确认因果再动下一个；一次改十个参数后性能变了，你说不清是哪一行起效、更说不清哪一行在帮倒忙。第三步，留回滚路径——参数文件按变更归档（/etc/sysctl.d/99-2026-11-05-app.conf 这种带日期的命名），出问题 sysctl --system 回滚到上一版即可，分钟级恢复。第四步，重载验证——改配置文件后必须 sysctl --system 并逐条 sysctl <参数名> 核对实际值，因为参数名写错时 sysctl -w 不报错的情况只有手动 echo 才会暴露（sysctl 命令对不存在的键会报 "cannot stat /proc/sys/...: No such file or directory"，而写配置文件时拼错的行会被静默跳过，只留下 dmesg 里一行日志）。另外一个环境差异要点：systemd 系发行版由 systemd-sysctl 加载，但某些精简容器镜像没有这套机制——在容器里做参数持久化要靠镜像内的启动脚本显式执行，不能照搬宿主机惯例。

小结

sysctl 是内核参数的统一暴露面：/proc/sys 树形结构 + /etc/sysctl.d 的字典序加载链，写操作即时全系统生效、持久化靠 systemd-sysctl 启动加载。高频参数的取值都能从默认值推导出硬约束：somaxconn 钳住 listen backlog（必须与应用侧一起改，溢出证据在 netstat -s 的 overflow 计数器）、ip_local_port_range 的 28232 个端口除以 TIME_WAIT 的 60 秒给出约 470 QPS 的同目标出站上限（解法是扩池、tw_reuse 与连接复用）、nr_open 抬起来 ulimit -n 才能上百万、overcommit_memory 的 0/1/2 三档对应「启发式/来者不拒/申请即承诺」三种故障形态（数据库类建议 2）。容器的关键是参数的 namespace 隶属：net.* 每 netns 独立副本可按容器设置，vm./fs. 全局生效或被拒，运行时白名单把这个边界制度化——主机级参数回节点层配，netns 级参数进 Pod spec。方法论的底线是基线、单变量、可回滚：先有度量再动参数，一次一组，配置带日期归档。调优脚本的正确打开方式不是执行它，而是逐行审它——每个参数问一句「它约束的硬限制是什么、我的故障形态对得上吗」，对不上就删，这才是 sysctl 知识的真正杠杆。