Postgresql和NUMA

白鳝的洞穴 2021-06-08

3484

凡是DBA，无论你管理的是哪种数据库，都不可避免地要和内存管理打交道。和内存管理打交道，就绕不开NUMA的问题。以前老白多次和大家讨论过ORACLE数据库与NUMA，实际上Postgresql和NUMA的关系也是一样的。

NUMA架构是大型SMP服务器为了解决内存IO性能问题而设计的一种架构，在NUMA架构下，所有的内存都会连接到某个CPU组上，其他CPU要访问这组内存都需要其他的CPU帮助读取和传输。CPU的核数越多，这种架构的内存访问的成本开销越大。不过对于绝大多数的数据库系统来说，NUMA并不会带来十分明显的问题，因为现在的LINUX操作系统越来越好的帮我们优化了这个问题，让RDBMS读取内存的时候，可以忘记NUMA的存在。因此在绝大多数数据库系统中，我们可以使用十分简单的策略来对待NUMA问题。

在服务器的BIOS上，我们可以通过启用 memory interleaving来确保服务器启用NUMA节点之间的内存互访。在LINUX系统启动的时候，我们需要使用numa off参数，确保LINUX启用时关闭NUMA。

如果你没有在BIOS和OS启动时采用上面的措施，你还可以通过下面的方式启动PG来达到类似的效果。

采用了上述措施后，你的PG数据库在NUMA下一般情况下就能够很好的运行了。如果你的一台数据库服务器上运行了多个PG数据库，那么让每个PG数据库实例使用不同的CPUSET是一个比较好的方法。当然，如果你的数据库都较小，访问并发量不大，那么不做这样的处理也是没有问题的。如果你的多个数据库的负载都很大，而且经常出现SYS CPU很高，或者部分CPU核十分繁忙，数据库的性能也有下降的情况，那么你就应该考虑CPUSET了。

如果你的PG数据库遇到了类似上图的情况，那么，那么我们首先要怀疑的就是NUMA引起了这个问题。为什么NUMA架构下，PG数据库会遇到此类问题呢？这种情况往往会出现在LINUX 7之前的OLTP系统中。如果我们的PG数据库并发访问量十分大，而且数据库中存在部分十分热的数据，这种情况就很可能出现。因为分配shared buffer的时候，有可能因为buffer大小与NUMA节点的分配策略重合，那么shared buffer可能大多数分配在同一个NUMA节点内存中，这些BUFFER如果特别热，那么PG数据库在访问远程内存的时候，需要通过SPIN lightlock来做串行化处理。因为访问这些十分热的BUFFER会导致部分CPU十分繁忙，同时SPIN轻量级锁的开销十分大。

要解决这些问题也不难，因为在LINUX 7之后，OS对这方面的性能有了相当大的提升，升级OS可能就会解决这个问题。如果暂时你无法升级OS，那么调整SHARED BUFFER的大小，将内存分配打散到多个numa节点上也可以缓解这个问题。另外调整PG使用的CPUSET也可以改善这个问题。

总之，在绝大多数情况下，PG和NUMA的矛盾并不突出，并且当NUMA问题出现的时候，还是有相应的措施的，大家也不必过度担心NUMA的问题。在一般情况下，使用PG数据库的时候，采用在BIOS和OS启动参数上做设置是最为简单的方法。如果你的数据库比较大，负载比较高，那么还是建议不要忽视这个问题。

postgresql

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

Postgresql和NUMA

评论

相关阅读