PolarDB PG支持NUMA Aware

[fengzunbao]

背景

PolarDB PostgreSQL中的核心数据结构，运行期内存，以及数据库进程分布会在不同的NUMA Node上，导致跨频繁的跨NUMA远程访问内存。

情况1：

1. PGPROC数据是被频繁访问的结构，是在DB启动时静态的在共享内存中分配出来的；
2. 每个backend进程在启动时会分配一个PGPROC结构；
3. backend进程执行SQL时会频繁的读写该PGPROC结构，此处，该backend进程和PGPROC结构可能位于不同numa node；

情况2：

1. backend进程执行器中会分配大量的临时内存SQL执行完之后会释放（比如：hashjoin）；
2. 此处，baackend进程和分配出来临时内存可能位于不同numa node；

目标

对PostgreSQL核心数据结构架构升级改造，使得用户backend进程的执行的CPU和相关内存聚集到单个NUMA Node上，减少跨NUMA提升性能。

方案

1. 全局PGPROC数组平均分配在各个numa node上；
2. backend进程启动之后，获取到PGPROC结构（该结构可能位于任意的numa node上，取决于运行时分配和释放情况）；
3. 情况1的方案：把该进程绑定该PGPROC所在numa node上，这样能保证该进程和PGPROC在一个numa node上；
4. 情况2的方案：把该backend进程在分配内存时也绑定到该numa node上，这样能保证该进程和临时分配的内存也在一个numa node上；

[Cerdore]

您好！

情况1看起来更像是保证tp类操作的性能，而2是侧重ap类的性能。
PolarDB的AP和TP是节点物理隔离的，所以是不是不需要考虑单节点上情况1和2的隔离？

[Cerdore]

这里的情况2也不能完全算作olap相关的...

[fengzunbao]

”情况1看起来更像是保证tp类操作的性能，而2是侧重ap类的性能。“ -- 此处的描述有一定道理；但是情况1和2都需要在单节点上优化，应该都有收获

[Carefree98]

个人简介
Hello！我是来自浙江大学的张典典，目前研究生一年级，对数据库、Linux内核感兴趣。
课题理解：
众核时代，numa架构意味着cpu访问绑定的numa node内存块效率高，跨numa node访问内存会降低效率。所以本课题的核心在于改造pgproc数据结构，使得数据库后台进程（backend）在情况1、2中需要频繁访存的内存，和执行backend进程的cpu核要尽可能的一致，减少跨numa node访存。

• 情况1：pgsql中postmaster以守护进程的方式对数据库进行初始化，此时会在共享内存中初始化一个全局变量procarray（ProArrayStruct结构体类型），procarray用于记录procglobal中已经注册的后端进程数量、映射表等其他信息。当存在client对数据库发起连接，postmaster总会第一个接到该连接，随后通过fork启动一个postgres服务进程，将该连接从postmaster上移除至新启的postgres进程上。在启动postgres子进程的时候，就会初始化一个backend类型的结构体变量。每个backend都会在共享内存中有一个对应的PGPROC结构体变量，用来维护、跟踪这个backend的状态、pid、事务id、加锁解锁等等信息。（此外还有一个PGXACT结构体跟他关系紧密）。backend在执行sql操作的时候会频繁的访问对应的PGPROC变量，为了防止频繁的跨numa node访存，需要尽可能让“backend进程的执行cpu”和“backend对应pgproc变量所在内存对应的cpu核”是同一个cpu核。

• 情况2：backend进程需要访问分配/释放临时内存的内存块。动机与情况1相同，为了避免跨numa node访存，需要让内存块尽可能在backend的执行cpu的对应内存node上。

解决方案：
1.为避免某个numa node内存/对应cpu被分配大量的backend进程，需要尽可能的均匀打散。这一步可以通过哈希来实现。
2.或许可以考虑通过ProcGlobal、allProcs、freeProcs等链表，根据链表中元素pgproc维护的backend信息，如pid等进行查找，获取到PGPROC结构。
3和4的重点在于：确定backend访存内存块（PGPROC和运行期临时内存）所在的numa node，并将该backend进程绑定到这个node对应的cpu核上。将进程绑定到指定的cpu核心上可以通过：sched_setaffinity实现。（线程也有类似接口）

#define _GNU_SOURCE             /* See feature_test_macros(7) */
#include <sched.h>

/* 设置进程号为pid的进程运行在mask所设定的CPU上
 * 第二个参数cpusetsize是mask所指定的数的长度
 * 通常设定为sizeof(cpu_set_t)

 * 如果pid的值为0,则表示指定的是当前进程 
 */
int sched_setaffinity(pid_t pid, size_t cpusetsize, cpu_set_t *mask);

int sched_getaffinity(pid_t pid, size_t cpusetsize, cpu_set_t *mask);/* 获得pid所指示的进程的CPU位掩码,并将该掩码返回到mask所指向的结构中 */

疑问：
1.”通过ProcGlobal、allProcs、freeProcs等链表，根据链表中元素pgproc维护的backend信息，如pid等进行查找，获取到PGPROC结构“这样的作法有可行度吗？
2.假设上述获取到了PGPROC，如何进一步获取该变量内存所在的numa node（以及对应的cpuX核id编号）呢？

[Carefree98]

补充
根据资料查到如下接口可以实现：获取内存页、numa node id、cpu id之间的对应关系

1. 通过raw_smp_processor_id()得到当前cpu id
2. numa_node_id = cpu_to_node(raw_smp_processor_id())

static inline int numa_node_id(void)
{
    return cpu_to_node(raw_smp_processor_id());
}

3. 根据page->flags 中的属性来得到当前内存页所属的numa id

static inline int page_to_nid(const struct page *page)
{
    return (page->flags >> NODES_PGSHIFT) & NODES_MASK;
}

[fengzunbao]

关于情况1和2的背景理解是十分精确的。
”如何进一步获取该变量内存所在的numa node（以及对应的cpuX核id编号）呢？“
方法是：PGPROC在分配的时候就绑定到某个numa node上，并记录到PGPROC结构体里面。

[Carefree98]

老师您好：

对于情况1、2的解决方案，存在一点疑惑：
上述描述了三者之间的绑定关系：backend、运行期临时内存、PGPROC结构体变量。

• PGRPOC在backend进程创建之后，相当于是被静态分配在了某个node上，不会随backend的执行而改变所在node，此处称其为node_1。

• 运行期临时内存，取决于backend执行SQL期间的各node的内存情况，可能被分配到任意node上，既然是临时内存，我的理解是可能随着backend的SQL执行期间，被多次“随机”分配和释放在某个numa node上，此处称其为node_X，表示其在backend执行期间可能存在变化。

• 我们能改变的，或者说容易改变的是backend的执行cpu，可以将其绑定到上述node_1或者node_X上。

我的疑惑是：
按照上述解决方案的描述，似乎为了解决情况1、2，我们需要在面临不同情况的时候，动态的调整backend绑定的CPU？举例，当backend被初始化，将其绑定在PGPROC所在node_1上，而当某次执行SQL的时候，分配临时内存在node_2上，我们再将backend从node_1解绑，重新绑定到node_2上？当后续多次执行SQL，而临时内存又可能被分配到node_3、node_4上，需要再次重复上述过程，重新绑定backend的执行cpu。（node_X = node_2,node_3,node_4,...）

1. 上述动态绑定backend的理解是正确的吗？
2. 如果是正确的，这样多次的绑定操作是否也会带来一些额外的性能开销呢？绑定node的动机是降低访存开销，如果频繁的解绑、绑定node带来的性能开销更大，似乎得不偿失了。（对绑定node操作的性能开销不是很了解）

[fengzunbao]

1. 当backend被初始化，将其绑定在PGPROC所在node_1上；
2. 步骤1完成之后，numa_run_on_node来控制后续内存的分配，不需要再次绑定了；
   整个过程最多只需要一次绑定cpu

[Carefree98]

好的，明白了，感谢😀