如何解决供应链管理中的痛点？

图 6 - 分配均匀的内存

该问题并不是 MySQL 独有的，很多占用大量内存的数据库都会遇到上述问题，虽然使用 interleave 能够暂时解决这些问题，但是 MySQL 进程访问远程内存时，与本地内存相比仍然会遇到性能损失，想要一劳永逸地避免服务在 NUMA 上运行的额外开销，最好的办法还是开发能够感知底层 NUMA 架构的应用程序。以 MySQL 为例，Jeremy Cole 在文章中提出了如下的修改，可以更好地利用 NUMA 的本地内存[^9]：

• 将缓存池中的数据按照块或者索引智能地分配到不同节点上;
• 为正常的查询线程保留默认的分配策略，内存还是会优先分配本地节点上;
• 将简单的查询线程重新调度到能够访问本地内存的节点上;

除了 MySQL 可以利用 NUMA 来提高性能之外，一些框架或者编程语言也可以通过感知底层的 NUMA 信息来提升服务的响应速度，例如 Go 语言社区中就有关于 NUMA 感知调度的设计文档[^10]，虽然由于该特性的实现过于复杂，目前没有投入到开发中，但是这仍然是调度器未来的发展方向。

总结

很多软件工程师可能认为操作系统以及底层的硬件与我们的距离非常遥远，我们在开发软件时不需要考虑这么多细节，对于绝大多数的应用程序来说，这一点都是成立的，操作系统能够为我们屏蔽很多底层的实现细节，让我们能够将更多的精力投入到业务逻辑的实现上。

不过正如我们在文章中提到的，哪怕操作系统做出再多的隔离和抽象，物理世界存在的限制还是会在暗处影响我们的应用程序，想要开发高性能的软件必须要关注下两层甚至更底层的实现细节，NUMA 这种硬件层面的设计就会深刻的影响我们的软件，这里再来回顾一下文章开头提到的两点影响：

• NUMA 引入了本地内存和远程内存，CPU 访问本地内存的延迟会小于访问远程内存;
• NUMA 的内存分配与内存回收策略结合时会可能会导致 Linux 的频繁交换分区(Swap)进而影响系统的稳定性;

我们当然更希望主机上的所有 CPU 都能够快速地访问全部的内存，但是硬件的限制导致我们无法实现这么理想的情况，而 NUMA 可能是 CPU 架构发展的必然方向，通过将 CPU 和内存资源分组降低总线的压力，让单个主机容纳很多的 CPU。到最后，我们还是来看一些比较开放的相关问题，有兴趣的读者可以仔细思考一下下面的问题：

NUMA 架构最多可以支持多少 CPU?该架构又存在哪些瓶颈?

MPP(Massive Parallel Processing)是如何扩展系统的?它解决了哪些问题?
 

图 5 - 分配不均匀的内存

因为 MySQL 等数据库的运行会占用大量的内存，在默认情况进程会先在所在的 NUMA 节点上分配内存，当本地内存不足时，才会在远程分配内存。如上图所示，主机上包含两个 NUMA 节点，其中每个节点都有 32GB 的内存，但是当 MySQL InnoDB 的缓存池占用 48GB 的内存时，它会在 NUMA 节点 0 和 NUMA 节点 1 分别分配 32GB 和 16GB 的内存。

虽然 48GB 的内存远远没有到达主机 64GB 的内存上限，但是当某些数据必须要在 NUMA 节点 0 的内存上分配时，就会导致 NUMA 节点 0 中的内存被交换到了文件系统上为新的内存请求让出位置[^5]，InnoDB 缓存池中内存的频繁换入和换出会使 MySQL 的查询随机地出现延迟，而一旦发生了交换分区，可能就是性能螺旋下降的开始。

Linux 中的 zone_reclaim_mode 可以允许工程师设置在 NUMA 节点内存不足时内存的回收策略，在默认情况下该模式都会处于关闭状态[^6]，如果我们在 NUMA 系统中通过该配置启用了激进的内存回收策略，可能会影响程序的性能[^7]，MySQL 也会受到内存回收策略的影响，但是仅仅关闭该策略并不会解决它遇到的频繁触发交换分区的问题[^8]。

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!