PostgreSQL数据库共享内存——概览

Myth丶恋晨 2022-10-19 14:56 725阅读 0赞

## 何为共享内存 ##

我们知道，PostgreSQL是多进程模型，进程间通信(IPC)的方式有很多种，比如管道、消息队列、信号量、Socket和共享内存等。

共享内存的机制，就是拿出一块虚拟地址空间来，映射到相同的物理内存中。这样这个进程写入的东西，另外一个进程马上就能看到了，都不需要拷贝来拷贝去，传来传去，大大提高了进程间通信的速度。所以共享内存可以说是最有效的进程间通信方式，也是最快的IPC形式。假设有两个不同进程A、B，那么会有同一块物理内存被映射到进程A、B各自的进程地址空间。进程A可以即时看到进程B对共享内存中数据的更新，反之亦然。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70]  
PostgreSQL的shared memory总共支持3种：

*  sysv
 *  windows
 *  mmap  
    dynamic shared memory 动态共享内存支持4种：
 *  posix
 *  sysv
 *  windows
 *  mmap

## 基础概念 ##

Posix 表示可移植操作系统接口（Portable Operating System Interface ，缩写为 POSIX ），POSIX标准定义了操作系统应该为应用程序提供的接口标准，是IEEE为要在各种UNIX操作系统上运行的软件而定义的一系列API标准的总称，其正式称呼为IEEE 1003，而国际标准名称为ISO/IEC 9945。  
System V，曾经也被称为 AT&T System V，是Unix操作系统众多版本中的一支。它最初由 AT&T 开发，在1983年第一次发布。一共发行了4个 System V 的主要版本：版本1、2、3 和 4。

Posix提供了两种共享内存的方法：

*  内存映射文件(mmap)
 *  共享内存区对象

Linux提供了内存映射函数mmap, 它把文件内容映射到一段内存上(准确说是虚拟内存上，运行着进程), 通过对这段内存的读取和修改, 实现对文件的读取和修改。mmap()系统调用使得进程之间可以通过映射一个普通的文件实现共享内存。**普通文件映射到进程地址空间后，进程可以像访问内存的方式对文件进行访问，不需要其他内核态的系统调用(read,write)去操作**。

POSIX接口的共享内存，底层最终都是调用的mmap，只是不同的是共享内存打开文件调用shm\_open()，而内存映射调用open()。只是说mmap并不完全是为了共享内存来设计的，它本身提供了不同于一般对普通文件的访问的方式，进程可以像读写内存一样对普通文件进行操作，IPC的共享内存是纯粹为了共享。所以，**共享内存在POSIX上一定程度上就是指的内存映射**了。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 1]  
对于共享内存区使用的API shmopen()，传入的参数叫shmname，宏中声明了shmname，构造出shmdir，shm\_dir的内容就是/dev/shm/，之后通过和name拼接：  
![在这里插入图片描述][20210711173128223.png]  
生成了shm\_name。等等，/dev/shm是个什么鬼？  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 2]  
翻译一下：tmpfs是一个文件系统，可将所有文件保留在虚拟内存中。tmpfs中的所有内容都是临时的，因为没有文件会在硬盘上创建。如果您卸载tmpfs实例，存储在其中的所有东西都会丢失。由于tmpfs都存在于page cache和swap中，因此所有tmpfs当前在内存中的页面都会显示在cache里面。它不会作为shared或类似的东西出现。可以使用df(1)和du(1)来检查tmpfs真正使用的RAM + SWAP量。  
原来是一个特殊的文件系统，看一下确实贺然写着tmpfs。  
![在这里插入图片描述][20210711173207344.png]  
于是总结一下，Posix的两种共享内存区的区别在于共享的数据的载体(底层支撑对象)不一样：

1.  内存映射文件的数据载体是物理文件
2.  共享内存区对象，共享的数据载体是物理内存
3.  另外共享内存和文件内存映射的接口、用法不一样，一个是open()，另一个是shm\_open()，POSIX的共享内存实现会默认把共享内存文件放在/dev/shm/分区下，如果没有这个分区，需要手动挂载一下。

## 对比 ##

System V的方式，两个进程都通过虚拟地址空间到page table，然后通过page table映射到物理内存的同一块内存区域，这样就可以实现IPC：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 3]  
POSIX的方式，最终通过mmap，每个进程地址空间中开辟出一块空间进行映射：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 4]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 5]  
MMAP：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 6]  
shared buffer history  
Prior to PostgreSQL 9.3, only System V shared memory was used, so the amount of System V shared memory required to start the server was much larger. If you are running an older version of the server, please consult the documentation for your server version.

PostgreSQL有自己的shared\_buffer，在<=9.2时，PostgreSQL是基于SYSTEM V的API，SYSTEM V的接口要求设置SHMMAX大小，所以低版本会让我们设置一大堆shmmax、shmall等，十分麻烦。而>=9.3之后，PostgreSQL大多数基于POSIX的API实现。而System V共享内存，仅用于提供互锁来保护数据目录，量很少。

If you’re on posix system without mmap, you’d use posixshm. If you’re on a unix without posixshm you’d use sysv\_shm. If you only need to share memory vs a parent/child you’d use mmap if available.

## Shared\_buffers又来了 ##

玩PostgreSQL的，对这玩意应该是最常打交道的了，什么推荐25% ~ 40%，什么double buffer，这些都暂且不论。今天只看shared\_buffers的底层实现方式。在postgresql.conf配置文件里写的很清楚，默认使用的方式是mmap：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 7]  
在源码里面，主要是这个CreateAnonymousSegment->mmap，里面会用到mmap的方式。ptr = mmap(NULL, allocsize, PROTREAD | PROTWRITE,PGMMAPFLAGS | mmap\_flags, -1, 0);  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 8]  
用pmap看一下postmaster的，只需关注zero(deleted)这一坨即可  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 9]  
其实/zero是/dev/zero，可以看到大小为146536 kB，这个其实就是sharedbuffers，你要说这个大小也对不上啊？注意实际申请占用的共享内存比sharedbuffers稍大是正常的，可以用gdb跟一下。

至于为什么是/dev/zero呢？这和mmap的实现方式有关，如果仅仅是父子进程之间的共享内存，第一种方式就是将 mmap 映射到 /dev/zero，因为 /dev/zero 是一个特殊文件，任何写都被忽略，并且一旦映射存储区，内容都将被初始化为 0。因为PostgreSQL就是通过postmaster来fork子进程服务的，所以理解了，/dev/zero就是PostgreSQL里面的shared buffers。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 10]  
我们可以再看一下checkpoint和bgwriter的，可以看到，大小也是 146536 kB  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 11]  
提到shared\_buffers，那么也不能避免讨论另一个话题了，在PostgreSQL里面，由于进程间基于shared memory通信，假如此时一个backend process异常断开，就比如常见的kill -9了某一个backend process，那么此时PostgreSQL大概率会crash，因为不幸把shared memory弄坏了，Postmaster只能进行修复工作。对应的日志如下：  
![在这里插入图片描述][20210711173559364.png]  
所以在PostgreSQL里面不要用kill -9，用自带的pg\_terminate\_backend和pg\_cancel\_backend，就算kill，也用不带参数的kill，友好地退出。之前白大师分享过一篇文章《为啥不能KILL -9杀PostgreSQL进程》，引用一下：Oracle的后台进程pmon就是负责死进程和会话的清理工作的，当有任何一个进程出现问题异常死掉后，会由pmon做善后工作，释放相关的资源，并且做一些善后修复工作，PostgreSQL因为没有这些，所以要务必注意。

## 动态共享内存 ##

前面说完shared\_buffers，还有一个动态共享内存也绕不开，除非你玩的是9.6以前的版本。dynamic shared memory 在并行中会用到，对于并行查询而言，执行时创建的 worker 进程与 leader 进程通过共享内存实现数据交互。但这部分内存无法像普通的共享内存那样在系统启动时预先分配，毕竟直到真正执行时才知道有多少 worker 进程，以及需要分配多少内存。动态共享内存，即在执行时动态创建，用于 leader 与 worker 间通信，执行完成后释放。基于动态共享内存的队列用于进程间传递元组和错误消息。如下图，每个 worker 在动态共享内存中都有对应的元组队列和错误队列，worker 将执行结果放入队列中，leader 会从对应队列获取元组返回给上层算子。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 12]  
Linux上面，只有posix、system v和mmap。创建和管理动态共享内存是操作系统的任务。创建完成后，会对动态共享内存段的“引用计数”reference-counted，这个其实和以前分享的sharedbuffers里面的buffer descriptors layer类似，里面包括usage和refcount，refcount保存当前访问相应页面的PostgreSQL进程数，也被成为“钉数”，当PostgreSQL进程访问相应页面时，其计数增加1，refcount ++，访问结束后引用计数减少1，refcount --，当refcount为0，即页面当前未被访问时，页面被取消“钉”，否则会被“钉”住，而usagecount保存着相应页面加载到相应缓冲池槽后的访问次数。

这样通过“引用计数”来判断，以便在删除最后一个映射后，该段就会自动消失。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 13]  
动态共享内存，配置文件里也写的很清楚，默认是mmap  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 14]  
启动之后，会在pg\_dynshmem子目录下有所体现：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 15]  
关了之后就没了  
![在这里插入图片描述][20210711173722520.png]  
重启之后，会重新分配  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 16]  
当改为POSIX类型时，如之前所述，会在/dev/shm目录下  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 17]  
The use of the mmap option, which is not the default on any platform, is generally discouraged because the operating system may write modified pages back to disk repeatedly, increasing system I/O load;，不是很推荐MMAP，因为会加剧IO的压力。另外，POSIX的性能优于MMAP。引用一下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 18]  
BenckmarkSQL的测试结果

<table> 
 <thead> 
  <tr> 
   <th>Clients</th> 
   <th>POSIX tps</th> 
   <th>MMAP tps</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>2</td> 
   <td>529</td> 
   <td>227</td> 
  </tr> 
  <tr> 
   <td>4</td> 
   <td>860</td> 
   <td>569</td> 
  </tr> 
  <tr> 
   <td>6</td> 
   <td>2308</td> 
   <td>1493</td> 
  </tr> 
  <tr> 
   <td>8</td> 
   <td>37734</td> 
   <td>31418</td> 
  </tr> 
  <tr> 
   <td>10</td> 
   <td>66453</td> 
   <td>67267</td> 
  </tr> 
 </tbody> 
</table>

## 小结 ##

前面总结了一下PostgreSQL共享内存的实现方式，以及种类，还有底层原理，相信读完可以进一步加深我们的理解。另外知道了这些，还得大概知道Linux下面内存的去向，主要有：

*  page 管理,page table
 *  slab（kmalloc、内存池）
 *  用户态内存使用（malloc、relloc 文件映射、共享内存）
 *  程序的内存 map（栈、堆、code、data）
 *  内核和用户态的数据传递（copyfromuser、copytouser）
 *  内存映射（硬件寄存器、保留内存）
 *  DMA 内存  
    另外，昨日请教了一下大老板，随着系统的运行，每个backend process的/dev/zero的rss会越来越多，在监控内存使用时，要将每个backend process中的/dev/zero的rss部分去掉。

参考：https://postgreshelp.com/postgresql-dynamic-shared-memory-posix-vs-mmap/  
https://leopard.in.ua/2013/09/05/postgresql-sessting-shared-memory\#.YG7HVugzbZQ  
https://www.geeksforgeeks.org/posix-shared-memory-api/  
https://www.postgresql.org/docs/12/kernel-resources.html\#SYSVIPC  
http://rhaas.blogspot.com/2013/10/parallelism-progress.html

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70]: /images/20221004/68b44e604f2e4f67a2d67048e9217f06.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 1]: /images/20221004/b9548138e3564b4da68c5c7e18958f2e.png
[20210711173128223.png]: /images/20221004/e2cdd0eafa6346a79f4e50d829a34deb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 2]: /images/20221004/737cc0791b824aa98df4d0a16966f1db.png
[20210711173207344.png]: /images/20221004/bd132ca515524b5eb4763eebb9e81f1a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 3]: /images/20221004/79585d6ab1cd4bf1b41da0f3c8f33cb0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 4]: /images/20221004/f96fdab884734a30bdc52e1db77d8e7d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 5]: /images/20221004/2ff672e876824a66adace47cfc90915d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 6]: /images/20221004/d1d2a5ce894941c69d8184c9714835ce.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 7]: /images/20221004/dedc6ef51ccf4e6fb5e2e102499e7b6a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 8]: /images/20221004/33d60b51fcea489b911ecb1ab89fbfbe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 9]: /images/20221004/7d55fac31f4040d3a788006173d02b04.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 10]: /images/20221004/472a0b5f6637460889eba2b8ee916efc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 11]: /images/20221004/21ee06ad03ef431b90f78366cef6be02.png
[20210711173559364.png]: /images/20221004/d427c9cabb8c4d239d56b777552db6e7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 12]: /images/20221004/d385b9bdba744adabf67defe37e1fea9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 13]: /images/20221004/70cc50ba974a4e9ea3d115087c8261cf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 14]: /images/20221004/da01acdbc6cc474e9477ee7684014198.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 15]: /images/20221004/5dda4562abd9411386a1bbc0f09bef5b.png
[20210711173722520.png]: /images/20221004/6efb0510fc8841c899dd803450ca1878.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 16]: /images/20221004/032e15be26514506840cf9194ef87df3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 17]: /images/20221004/c4a9f93b1e2040b9b53246f226b26515.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 18]: /images/20221004/137612e558bb430d95ceab2f7440444e.png