操作系统层调优：Linux内核参数调优

聊到消息总线的性能，很多人第一反应是改代码、调线程池。但我做了这么多年中间件，发现一个有意思的现象：很多性能问题，根子其实在操作系统层面。你代码写得再漂亮，内核参数没配好，就像给法拉利加了劣质汽油——跑不起来。

这一章，我带你看看Linux内核里那几个跟消息总线吞吐量息息相关的参数。嗯，咱们一个一个来。

vm.swappiness：别让内存成为瓶颈

先问个问题：你的消息总线进程，内存够用吗？

很多场景下，消息总线（比如Kafka、RocketMQ）会大量使用Page Cache来加速读写。但Linux内核有个“坏习惯”——它倾向于把不常用的内存页换到磁盘上，哪怕物理内存还很充裕。这个倾向程度，就是vm.swappiness控制的。

默认值是60。什么意思？说白了，内核会相对积极地使用swap空间。但对于消息总线这种IO密集型的应用，这简直是灾难。

我个人习惯，在生产环境里，只要物理内存足够，我会把vm.swappiness设成1甚至0。为什么？因为一旦内存页被换出，下次访问时就会触发缺页中断，磁盘IO瞬间飙升。消息总线的延迟抖动，很多时候就是这么来的。

配置方法很简单：

# 临时生效
echo 1 > /proc/sys/vm/swappiness

# 永久生效（写入/etc/sysctl.conf）
vm.swappiness = 1

我曾经帮一家金融客户排查Kafka集群的性能抖动问题。他们的机器是128GB内存，Kafka的Page Cache用了大概60GB，但每隔几分钟就会出现一次明显的延迟毛刺。查了半天，发现vm.swappiness是默认的60。内核时不时就把一些Page Cache换出去了，等生产者写入时又得从磁盘读回来。改成1之后，毛刺消失了。

net.core.somaxconn：连接队列的“天花板”

消息总线作为服务端，要处理大量客户端的连接请求。这里有个关键参数——net.core.somaxconn。它定义了每个端口上，内核能排队的最大TCP连接数。

默认值是多少？128。你想想看，一个高吞吐的消息总线，瞬间可能有成千上万个客户端同时发起连接。128的队列长度，稍微一拥堵，连接就直接被拒绝了。

我建议，对于消息总线服务端，至少把这个值设到4096以上。配合应用程序的backlog参数（比如Netty的SO_BACKLOG），才能扛住连接风暴。

# 临时生效
echo 4096 > /proc/sys/net/core/somaxconn

# 永久生效
net.core.somaxconn = 4096

这里有个坑：光改内核参数不够。你的应用程序在监听端口时，也要设置对应的backlog大小。比如Java NIO里：

ServerSocketChannel.open()
    .bind(new InetSocketAddress(port), 4096); // 第二个参数就是backlog

如果应用层只设了128，内核层设再大也没用。嗯，这个我踩过。

文件描述符限制：别让“句柄用尽”搞垮你

消息总线要管理大量连接、打开大量文件（比如Kafka的Segment文件）。每个连接、每个文件，在Linux里都是一个文件描述符（File Descriptor）。

默认的ulimit限制通常是1024。对于消息总线来说，这连热身都不够。

我记得有一次线上事故，Kafka Broker突然无法接受新连接，日志里全是“Too many open files”。一看，文件描述符用到了1024，触顶了。扩容？不，改个参数就行。

你需要调整两个地方：

1. 用户级别限制（ulimit）：
2. 系统全局限制（fs.file-max）：

# 查看当前限制
ulimit -n

# 临时修改（当前会话）
ulimit -n 100000

# 永久修改（/etc/security/limits.conf）
* soft nofile 100000
* hard nofile 100000

# 系统全局限制（/etc/sysctl.conf）
fs.file-max = 500000

对于消息总线进程，我一般建议设到100000以上。具体多大，取决于你的连接数和文件数。你可以用lsof -p [pid] | wc -l来监控实际使用量。

磁盘调度策略：选对“排队规则”

消息总线的数据最终要落到磁盘上。磁盘IO的调度策略，直接影响写入延迟和吞吐量。

Linux支持多种IO调度器：

调度器	特点	适用场景
CFQ (Completely Fair Queuing)	公平分配IO时间片	传统机械硬盘，多进程共享
Deadline	保证每个请求的截止时间	数据库、消息队列等延迟敏感场景
NOOP	简单FIFO，不做合并	SSD、NVMe等高性能设备
Kyber	基于延迟的调度	现代SSD，自动调优

我个人推荐：如果用的是SSD或NVMe，直接用NOOP或Kyber。因为这些设备本身就有强大的内部调度能力，内核再做一层调度反而是累赘。如果是机械硬盘，Deadline通常比CFQ更适合消息总线——它能保证写请求不被读请求饿死。

查看和修改方法：

# 查看当前调度器
cat /sys/block/sda/queue/scheduler

# 临时修改
echo noop > /sys/block/sda/queue/scheduler

# 永久修改（通过grub或udev规则）
# 在/etc/default/grub中添加：
# GRUB_CMDLINE_LINUX="elevator=noop"

文件系统选择：XFS vs Ext4

最后聊聊文件系统。消息总线的数据文件通常很大（比如Kafka的Segment文件动辄GB级别），而且写入模式是顺序追加。文件系统的选择，对性能影响不小。

主流选择是XFS和Ext4。我直接说结论：

• XFS：大文件、高并发场景下表现更好。分配组（Allocation Group）的设计让它能并行处理多个IO请求。Kafka官方也推荐XFS。
• Ext4：小文件、低并发场景下够用。但单个文件超过16TB时，Ext4的扩展性不如XFS。

我建议：对于消息总线数据盘，优先选择XFS。挂载时，记得加上noatime和nodiratime选项，避免每次访问都更新文件访问时间，减少不必要的IO。

# 格式化
mkfs.xfs -f /dev/sdb

# 挂载（/etc/fstab）
/dev/sdb /data xfs defaults,noatime,nodiratime 0 0

另外，千万不要用默认的Ext4的data=ordered模式？其实也可以，但如果你追求极致性能，可以试试data=writeback。不过要小心——它不保证元数据一致性，万一宕机可能丢数据。消息总线一般有副本机制，可以接受这种风险。嗯，这个看你的取舍。

知识体系总览

说了这么多，我画了一张图，帮你把这一章的核心逻辑串起来：

说白了，操作系统层调优就干一件事：把资源留给消息总线，别让内核瞎折腾。内存别乱换出，连接别随便丢，文件句柄别设太小，磁盘IO别用错调度器。这几步做到位，你的消息总线性能至少能提升30%。

嗯，下一章咱们聊聊JVM层怎么调。不过那是后话了，先把这些内核参数改好，跑几天看看效果。

---

公众号:蓝海资料掘金营，微信deep3321