“PostgreSQL“ 不重启机器就能调整 shared buffer pool 的原理

最新推荐文章于 2025-12-01 18:34:47 发布

原创

最新推荐文章于 2025-12-01 18:34:47 发布 · 895 阅读

10 ·

CC 4.0 BY-SA版权

文章标签：

#postgresql #数据库

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

上周三IF-Club直播了PostgreSQL的干货，当时公司在开会所以没有完整听到内容，不过好在拿到了当时直播的PPT，这里对这个部分进行学习，这里和大家进行一个分享。

王硕老师的PPT的图1

从上图中我们可以总结出以下内容

1 PostgreSQL 内存布局分为3个大的类型，这三个类型是

shared Memory , Priveate Memory , Dynamic Shared Memory，在我之前的PG学习中我其实是忽略了，DSM这个部分，这三个部分主要的功能。

Shared Memory（共享内存）：所有后台/会话进程共享，用来放Buffer Pool、WAL 缓冲、锁表、ProcArray、元信息等。图中大的深绿矩形“Buffer Pools / Others”即此区域。

Private Memory（进程独享内存）：每个 postgres 服务器进程自己的内存，采用 Memory Context 管理（例如 Portal/Executor/Parser 等上下文），在查询生命周期内分配释放，互不共享。

Dynamic Shared Memory（DSM，动态共享内存）：位于图底部“Dynamic Shared Memory Areas”。主要服务并行查询/并行算子等需要在多个进程之间临时共享数据的场景，生命周期随任务结束而回收。

PG内存学习

蓝色实线（postmaster → system/shared memory）：实例启动时创建共享内存（现代 PG 通过 mmap/POSIX SHM，早期为 SysV）。

蓝色虚线（子进程 → shared/system memory）：子进程 attach 已有共享内存，获得对共享结构的访问。

绿色实线：postmaster fork 各类后台/工作/会话进程。

黑色虚线双箭头：client 与 postmaster/backend 的连接请求与接受。

查询执行过程中（backend ↔ shared memory）会持续访问 Buffer Pool / WAL / 锁表等共享结构，并在需要时与 DSM 协作（并行）

这里串一下，Postmaster负责建立整体内存的架构，shared memory是整体的公共内存使用区域，private memory 是客户访问数据的内存，DSM是在客户访问内存式开启多进程访问的时候的内存赋予。这套设计让 PG 在多进程模型下既能保证一致性，又能在并行与高并发场景中保持伸缩与稳定。

Linux 地址分配从这个图中我们可以看到两大块，一块是User space 主要负责Postgres 可以访问的地址范围，另一个部分kernel space是用户进程不能访问到的内存部分。

User space (128 TB)

地址范围：0x0000000000000000 ~ 0x00007FFFFFFFFFFF

每个进程私有，可通过 mmap、brk 等系统调用分配堆内存、栈、文件映射、共享内存等。

PostgreSQL 的 backend 进程（postgres 进程）就在这个空间中运行,Kernel space (128 TB)

地址范围：0xFFFF800000000000 ~ 0xFFFFFFFFFFFFFFFF

保存内核代码（text）、数据、直接物理内存映射、vmalloc 区、I/O 映射、EFI、hypervisor、内核模块等。

这里我们关注的是 shared buffer pool resize 不进行重启，因为shared buffer pool 是在数据库启动时一次性的申请连续的共享内存区域，那么如果要动态的进行内存的后期分配，我们就需要将mmap固定大小的内存获取，改成预留一大片虚拟地址空间，在真正需要的内存的时候，在进行真正的物理内存的分配。

动态分配shared buffer pool resize

上图就是解释这部分如何进行动态内存分配 1 通过process virtual Memory address来设置虚拟机的地址空间，让每个数据库进程获取超大的连续的内存地址空间，然后在这个地址空间中，设置多个segment内存段，而这些段时可以单独扩展和单独卸载的，卸载就是相当于收缩了。

扩展也很方便，在虚拟地址空间中选择当前地址+偏移量的方式，扩展自己的虚拟空间，

image

下面着重讲一下此次我学到的内存动态扩展的部分。

PolarDB for PG 动态扩展内存

从这张图可以看到内存扩展的部分，resize shared buffer 的主要机制在，图中的 Dynamic Region 和 Polar Memory manager 这里是让PolarDB for PG 可以动态扩展的核心，他提供了一块动态申请和释放的公共的共享区域，具体的扩展过程为 Postmaster 创建和管理 Dynamic Region ，当需要扩展内存时，Memory Manager将产生新的共享内存块，并将这个信息广播给现在正在工作的各个进程，各个进程通过信号机制，收到通知后，重新加载新的共享区域，扩展完成后，所有的被通知的进程都报告工作完成，从而保证整体的系统都不用重启而完成 shared buffer pool 的 resize.

在整体的数据库系统设计中，关键就是图中的dynamic region，这里为了优化不同进程内存地址不统一的问题，PolarDB for PG通过postmaster启动时御前申请1T的虚拟地址空间，让所有的子进程都继承这段地址，这样所有的内存段迎神到相同的地址后，所有的变了的地址就完全相同了，无需进行重建和解析，直接映射物理的地址。

而图中的memory manager这个在PG上没有的进程的核心在，管理内存的生命周期，包括何时建立和何时注销这些内存，这就让扩展异常的简单，如果需要扩展内存容量，就新建一批buffer内存块，并将这些块加入到空闲内存列表，然后数据库就可以像原来一样，直接从free_list中获取这些新加如的内存块，得到扩展的shared buffer。

缩容则相对扩容要麻烦，因为这里包含了正在使用的内存不能被释放的问题，同时还有强制进行数据刷盘的工作等等。

学到这里，基本上理解了PolarDB for PG的动态的内存resize 和 dump unused buffer block的问题。

置顶

超强外挂让MySQL再次兴盛，国内神秘组织拯救MySQL行动

AI 很聪明，但就怕脑子失忆，记忆对AI很重要

从某数据库信任“危机”，简谈危机公关

邦邦硬的PostgreSQL技术干货来了，怎么动态扩展PG内存！

数据库信创话题能碰吗？今天斗胆说说

企业出海数据库设计问题一角，与政策动荡下的全球数据库产品

计问题一角，与政策动荡下的全球数据库产品

《数据库江湖邪修门派：心法五式全解》

微软动手了，联合OpenAI + Azure 云争夺AI服务市场