7.2 内核与应用层调参

7.2 内核与应用层调参

本节摘要：Linux 的出厂默认值是为通用负载定的，对象存储的高并发大吞吐要把其中十来个参数换掉。本节按"连接队列、缓冲区、盘调度、预读、句柄、扫描节奏"的顺序给出调参清单，每个参数附上"为什么动"的因果解释。

主线案例的第二层：内核默认值的账

7 章主线里那份没达标的验收报告，硬件层修完（RAID 切直通）后吞吐从六成爬到八成，剩下的差距在内核层。这不是玄学调参的邀请——下面每个参数都对应一条明确的因果链：默认值为什么小、对象存储为什么需要大、动过之后预期看到什么变化。没有因果解释的调参清单不值得执行，这是本节的立场。

连接与缓冲：让万兆真的能跑满

对象存储的流量模型是"海量长连接、大块顺序传输"，两个内核默认值在这里偏小：

# 连接接受队列:突发并发时避免握手被丢
sysctl -w net.core.somaxconn=4096

# TCP 收发缓冲上限:大块传输的窗口要放得开
sysctl -w net.core.rmem_max=67108864
sysctl -w net.core.wmem_max=67108864
sysctl -w net.ipv4.tcp_rmem='4096 87380 33554432'
sysctl -w net.ipv4.tcp_wmem='4096 65536 33554432'
​

因果链是这样的：带宽延迟积（带宽乘以往返延迟）决定一条 TCP 流需要的在途数据量，万兆跨机房的链路上，默认 128K 级的缓冲上限让单流带宽被死死压住；调大后，单流吞吐与并发流的总吞吐都会改善。somaxconn 则对应备份系统整点齐发的场景——默认 128 的接受队列在数百连接同时握手时开始丢包，客户端表现为莫名的连接超时。

盘层：调度器与预读

# NVMe/直通盘用 none（多队列轮询）,HDD 可用 mq-deadline
echo none > /sys/block/nvme0n1/queue/scheduler

# 预读:HDD 上调到 2048 KB 级,NVMe 默认即可
blockdev --setra 4096 /dev/sdb

# 每块盘确认:numa 轮询与旋转盘标记
blockdev --getra /dev/sdb
cat /sys/block/sdb/queue/rotational
​

调度器的因果链：对象存储自己已经在应用层把请求排好了队（纠删集并发、分片打散），内核里面向机械寻址优化的复杂调度器反而添乱。NVMe 配 none 让请求直达队列，HDD 配 mq-deadline 保住"读不被写饿死"的底线。预读则专治 HDD 顺序读的磁头等待——对象读取是典型的顺序流，把预读窗口开到 MB 级，磁头一次扫过的数据够内核慢慢喂。

持久化别忘了：sysctl 与 blockdev 都是运行时生效，要写进系统调优配置文件与 udev 规则，否则重启即还原。

句柄与线程：服务进程的余量

2.3 的 systemd 单元里已经动过 LimitNOFILE,这里补全因果：MinIO 的每个连接、每个打开的分片文件都占句柄，万级并发乘以纠删分片数，几万句柄是常态，默认 1024 会在业务高峰直接拒绝连接。文件系统层面再确认 aio-max-nr（异步 IO 事件上限）不低于百万级，NVMe 队列深度默认值在多数发行版已够用，不动。

MinIO 应用层的两个旋钮

内核之外，MinIO 自己有两个值得认识的配置面：

扫描节奏。3.2 的后台巡扫是 IO 消耗户，默认节奏在绝大多数硬件上无害，但低配硬件与业务高峰重合时可以放缓：

# 扫描速度档位:slow 会为业务让出更多 IO
mc admin config set fleet scanner speed=slow

# 分层数据路径:开启后小对象元数据内联优化更激进,读路径少一次跳转
# 该能力默认开启,确认未被关闭即可
mc admin config get fleet storage
​

存储类与配比。1.2 与 3.1 说过的纠删配比也属于"应用层调参"的范畴，而且是收益最大的一项——把通用桶从默认对半分调到 10+6,等效容量立刻多出两成，这是任何内核参数都给不出的改善。

图 7-2 调参的层次栈与验证路径

案例：主线报告的后两成怎么追回来

背景：硬件层修复后，验收吞吐仍差两成。

操作：按层次栈逐层排查。应用层：验收场景是大文件顺序吞吐，配比 10+6 无碍，扫描节奏改 slow 后高峰抖动消失但吞吐不变。内核层：抓包发现单流 TCP 窗口长期顶在默认上限——正是缓冲区参数的问题，调大 rmem/wmem 后单流带宽明显抬升；盘调度器确认已在直通盘上设为 none。复测：万兆打满，验收通过。

解读：这次"调参"真正起作用的只有两项——TCP 缓冲与扫描节奏，但证明它们有效靠的是层次化的排查与同口径复测。把十几条网上抄来的 sysctl 一次全上，也能"调好"，但下次出问题你会不知道该回退哪个。

变式：小对象场景（每秒操作数导向）的调参重心完全不同：句柄、连接队列、KES 缓存、客户端连接池，而 TCP 缓冲几乎无关——画像不同，清单不同，又一处"画像先行"的注脚。

本节要点回顾

• 每个参数带因果：默认值为什么小、我们为什么需要大、改后预期看到什么，三问答不出就不动。
• TCP 缓冲是吞吐场景的头号内核项：带宽延迟积决定窗口需求，默认值喂不饱万兆级链路。
• 盘层两件套：调度器按介质选，预读按 HDD 调大，全部持久化。
• 收益最大的在应用层：纠删配比的一步棋，胜过全部 sysctl 的总和。

参数都动完了，数字可信吗？下一节讲怎么压测才能得到值得签字的数字。

把参数固化成资产

调参最大的浪费不是调错，而是调好之后三个月在一次重启后无声丢失。所有本章动过的参数都有对应的持久化归宿，逐一对号：sysctl 项进系统调优目录下的独立配置文件，一次一主题；blockdev 的预读与调度器进 udev 规则，按盘类型匹配，新盘插入自动生效；句柄与重启策略在 systemd 单元里（2.3 已就位）；MinIO 侧的配置进环境变量文件与配置中心。四条归宿核对完毕，这组参数才算从"某次会话的操作"升级为"集群的配置资产"。

变更管理再补一条：每个持久化文件头部注明变更日期、依据的压测报告编号与执行人。三个月后有人问"这个值为什么是 67108864",答案应该是一行注释指向一份报告，而不是一次考古。参数会过时，但参数与证据的绑定关系不会——这是调参工作能沉淀为组织资产的关键。

最后提醒一次验证闭环：持久化完成后，重启一台测试节点，逐项核对参数确实随重启还原生效。持久化的验证动作只有重启这一条路，文档写得再好，不如重启一次。