十年后数据库还是不敢拥抱NUMA - 续篇
内容提要
本文讨论了NUMA对数据库性能的影响。作者测试发现，BIOS设置为ON时，无论操作系统设置是ON还是OFF，内存延迟都存在抖动。而当BIOS设置为OFF时，内存延迟稳定在一个平均值。作者认为设置numa=off在操作系统启动参数中是没有必要的，反而会隐藏NUMA结构。
延伸解读
BIOS与OS的NUMA设置：谁在真正控制内存交织？
文章测试表明，BIOS中的NUMA开关实际控制内存交织。当BIOS开启时，即使OS启动参数设置numa=off，内存延迟仍存在抖动，说明OS设置无法改变物理距离导致的性能差异。而当BIOS关闭时，内存延迟稳定为平均值，因为内存被交织到所有节点。这提示我们，OS层面的numa=off并不能消除抖动，反而可能掩盖NUMA结构。
内存延迟抖动：物理距离无法通过软件优化
文章强调，CPU到内存的物理距离决定了访问延迟，软件设置无法优化这个距离。测试中，BIOS开启时，不同核心访问同一内存节点的延迟差异显著（如68ns vs 100ns），这是因为核心与内存节点的相对位置不同。因此，试图通过OS参数消除抖动是徒劳的，必须从硬件或调度层面让程序尽量在本地节点运行。
测试工具差异：lmbench与mlc的对比
文章使用lmbench和Intel mlc测试内存延迟，结果数值不同（lmbench为68/100ns，mlc为81/145ns），但快慢差距比例一致。这反映了测试方法的差异：lmbench通过大规模数据读写获取平均值，而mlc可能更精确地测量特定核心的延迟。读者在评估NUMA性能时，应注意工具选择对结果的影响。
实践启示：不要用numa=off掩盖问题
基于测试，作者认为在OS启动参数中设置numa=off没有必要，且会隐藏NUMA结构，导致无法感知性能抖动。正确的做法是保持BIOS和OS的NUMA开启，并通过numactl等工具将进程绑定到特定节点，以减少跨节点访问。这有助于数据库等应用获得更稳定的性能。
Q&A
为什么在操作系统启动参数中设置numa=off不能解决数据库性能抖动问题？
因为CPU到内存的物理距离是硬件决定的，软件层面的设置无法改变这个距离。测试表明，当BIOS中NUMA开启时，无论OS启动参数是否设置numa=off，内存延迟都存在抖动；只有当BIOS中NUMA关闭时，内存延迟才会稳定为平均值。因此，设置numa=off只是隐藏了NUMA结构，并不能消除抖动。
BIOS中NUMA开启和关闭对内存延迟有什么不同影响？
BIOS中NUMA开启时，内存延迟存在抖动，不同CPU核心访问内存的延迟不同（如0核100ns，24核68ns）；BIOS中NUMA关闭时，内存延迟稳定在一个平均值（如85ns左右），因为内存被交织到所有物理内存条上。
什么是内存交织？它如何影响内存延迟测试结果？
内存交织是指将大块内存数据按cacheline拆分到多个物理内存条上，以提升带宽。由于不同内存条速度可能不同，大规模测试时延迟是平均值，而非最慢值。例如，lmbench测试得到的是平均延迟，而mlc测试可能得到更具体的快慢值。
lmbench和mlc测试内存延迟的结果为什么不同？
lmbench和mlc是两种不同的测试工具，测试方法不同导致结果数值有差异。例如，在BIOS开启NUMA且OS关闭NUMA时，lmbench测得0核延迟约100ns，而mlc测得约145ns。但两者反映的快慢差距基本一致，都表明NUMA开启时存在延迟抖动。
在NUMA架构下，如何减少数据库的性能抖动？
应尽量让程序稳定运行在同一个NUMA节点内，以减少跨节点访问内存带来的性能抖动。因为CPU到内存的物理距离决定了访问延迟，软件层面无法优化这个距离。
为什么说设置numa=off是掩耳盗铃？
因为设置numa=off只是让操作系统看不到NUMA结构，但物理上的内存距离差异依然存在，性能抖动并未消除。测试证明，BIOS开启NUMA时，即使OS设置numa=off，内存延迟仍有抖动。因此，这种做法只是隐藏了问题，而非解决问题。
