数据库（MySQL / PostgreSQL）是否应该关闭 irqbalance

下面给你一个明确结论 + 原理解释 + 可执行建议的答案，适用于 MySQL / PostgreSQL，并区分 单机 / NUMA / 云环境。

一、先给结论（非常重要）

数据库是否关闭 irqbalance，取决于你是否“人工接管了中断调度”。

总结表（直接可用）

场景	是否关闭 irqbalance	原因
单路服务器 / 普通云主机	❌ 不关闭	自动调度比人工更稳
双路 NUMA 服务器	❌ 通常不关闭	NUMA 感知分配更合理
已手动绑定网卡 / NVMe IRQ	✅ 必须关闭	避免被覆盖
极致低延迟数据库	✅ 关闭	保证中断可预测
云厂商托管数据库	❌ 不关闭	平台已调优

二、为什么“默认不该关 irqbalance”

1. 数据库严重依赖 I/O 中断

MySQL / PostgreSQL 对以下中断非常敏感：

磁盘 I/O 完成中断（NVMe / SATA）
网络中断（复制、客户端连接）
定时器中断（后台进程）

irqbalance 的价值：

防止中断集中在 CPU0
分散软中断负载
减少抖动和尾延迟

2. NUMA 系统下 irqbalance 是“正收益”

在双路服务器中：

设备物理挂在某个 NUMA 节点
irqbalance 会：
- 优先绑定到本地 CPU
- 减少跨 NUMA 内存访问

人工做得比它好很难。

三、什么时候必须关闭 irqbalance

场景 1：你已经手动绑定 IRQ

例如：

echo 000000f0 > /proc/irq/123/smp_affinity

此时：

irqbalance 会在下一轮重新分配，直接覆盖你的优化

结论：

手动 IRQ 绑定 ≠ irqbalance
二者只能选一个

场景 2：极致低延迟数据库

特征：

金融交易
高频写入
P99 / P999 延迟敏感

要求：

中断路径稳定
不允许动态漂移

此时建议：

关闭 irqbalance
固定 IRQ -> CPU
固定数据库进程 -> CPU

场景 3：数据库独占服务器

如果：

服务器只跑数据库
CPU 核心有明确分工

示例：

CPU0–1：系统
CPU2–15：数据库
CPU16–23：IRQ

👉 这类架构 必须关闭 irqbalance

四、MySQL / PostgreSQL 官方态度（工程现实）

MySQL

官方文档 不建议关闭 irqbalance
除非：
- 你明确知道每个中断位置
- 有完整压测数据支撑

PostgreSQL

更强调系统整体稳定
默认建议：
- 保留 irqbalance
- 优先调优 NUMA / hugepage / I/O

五、正确的实践路径（非常关键）

路径一：推荐（90% 场景）

开启 irqbalance + 不手动绑定 IRQ

只做：

NUMA 绑定数据库进程
合理设置 CPU 亲和性
调整 sysctl / I/O

路径二：高阶优化（10% 场景）

步骤必须完整：

停止 irqbalance
```
systemctl disable --now irqbalance
```
手动绑定 IRQ（网卡 / NVMe）
固定数据库进程 CPU 亲和性
固定 NUMA 内存策略
压测验证（不是凭感觉）

六、一个非常重要的误区（警告）

❌ “数据库性能不好 -> 先关 irqbalance”

这是错误做法。

正确顺序：

检查 NUMA
检查 I/O 调度
检查内存策略
再考虑 IRQ

七、简单判断规则（实战版）

回答以下问题：

你是否改过 /proc/irq/*/smp_affinity？
你是否知道网卡 / 磁盘挂在哪个 NUMA 节点？
你是否有压测对比数据？

如果 任一答案是“否”：

不要关闭 irqbalance

八、一句话工程总结

irqbalance 是数据库系统的“默认安全网”，只有在你完全接管 CPU 与中断调度时，才应该关闭它。