《postgresql指南--内幕探索》第八章 缓冲区管理
2021/7/13 2:06:50
本文主要是介绍《postgresql指南--内幕探索》第八章 缓冲区管理,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
缓冲管理器管理共享内存和持久存储之间的数据传输,并可能对 DBMS 的性能产生重大影响。
postgresql中缓冲区管理器,存储和后端进程之间的关系:
概览
缓冲区管理器结构
PostgreSQL缓冲区管理器包括一个缓冲区表、缓冲区描述符和缓冲池,这些将在下一节中介绍。缓冲池存储数据文件的页, 如表和索引,以及自由空间映射和可见性映射的页面。缓冲池是一个数组,数据的每个插槽存储数据文件的一页。缓冲池数组的索引称为buffer_id。
缓冲区标签
在PostgreSQL中,可以为所有数据文件的每个页面分配一个唯一的标记,即缓冲区标签。当缓冲区管理器收到请求时, PostgreSQL使用目标页面的缓冲区标签。
其中,关系文件节点用于定位页面所属的关系,关系分支编号用于定位关系文件的具体分支文件,页面块号则在具体分支文件中指明相应页面的偏移量。
缓冲区标签由三个值组成,分别是关系文件节点、关系分支编号和页面块号。第一个值分别代表了表空间、数据库和表的oid;第二个值代表关系表的分支号;一个关系可能有三种分支,分别是关系主体(main分支,编号为0)、空闲空间映射( fsm分支,编号为1)及可见性映射(vm分支,编号为2)。最后一个值代表页面号。
例如,{(16821, 16384, 37721), 0, 7} 标签表示,在某个表空间(oid=16821)中,某个数据库(oid=16384)的某张表(oid=37721)的 0 号分支( 0代表关系表本体)的第 7 号页面。再比如,缓冲区标签 {(16821, 16384, 37721), 1, 3} 表示该表空闲空间映射文件的三号页面。关系本体 main 分支编号为 0,空闲空间映射 fsm 分支编号为1。
后端进程如何读取数据页
步骤如下图:
(1)读取表或索引页时,后端进程会向缓冲区管理器发送包含该页的buffer_tag的请求。
(2)缓冲区管理器返回存储请求页的插槽的buffer_ID。如果请求的页未存储在缓冲池中,则缓冲管理器将页从持久存储加载到缓冲池插槽中,然后返回buffer_ID的插槽。
(3)后端进程访问buffer_ID的插槽(读取所需的页面)。
当后端进程修改缓冲池中的页面(例如向页面插入插入tuples)时,尚未刷新到存储的修改后的页面称为脏页。
页面替换算法
当所有缓冲池插槽都被占用,但请求的页面未被存储时,缓冲管理器必须在缓冲池中选择一个将被请求的页面替换的页面。通常,在计算机科学领域,页面选择算法称为页面替换算法,所选页面称为牺牲者页面。
自计算机科学出现以来,对页面替换算法的研究一直在进行;因此,以前提出了许多替换算法。从8.1版开始,PostgreSQL使用了clock sweep算法,因为它比以前版本中使用的LRU 算法更简单、更高效。
脏页刷盘
脏页最终应刷新到持久性存储,不过,缓冲区管理器需要其他的协助来执行此任务。在PostgreSQL中,两个后台进程 (checkpoint和backgroud writer) 负责此任务。
缓冲区管理器的结构
PG 的缓冲区管理器由三层组成,即缓冲表层、缓冲区描述符层和缓冲池层。如下图所示。
-
缓冲表层是一个散列表,它存储着页面的 buffer_tag 与描述符的 buffer_id 之间的映射关系。
-
缓冲区描述符层是一个由缓冲区描述符组成的数组。每个描述符与缓冲池槽一一对应,并保存着相应槽的元数据。
-
缓冲池层是一个数组。每个槽都存储一个数据文件页,数组槽的索引称为 buffer_id。
缓冲表
缓冲表层的作用是,根据后端进程发送的请求,创建目标页面的 buffer_tag(这个结构下面会讲,暂时将其理解为缓冲区中包含的一个磁盘块),然后将 buffer_tag 通过内置的散列函数映射到哈希桶槽,并分配 buffer_id, 即目标页面在缓冲池数组中存储的槽位的序号。
缓冲表在逻辑上可分为三部分: 散列函数、散列桶槽及数据项。为了避免哈希函数的冲突的发送,缓冲表采用了使用链表的分离链接方法来解决冲突。当数据项被映射至同一个桶槽时,该方法会将这些数据项保存在一个链表中。缓冲表层结构如下图所示:
数据项包括两个值,即页面的 buffer_tag 和包含页面元数据的描述符的 buffer_id。例如,数据项 Tag_A,id=1 表示,在 buffer_id=1 对应的缓冲区描述符中,存储着页面 Tag_A 的元数据。
缓冲区描述符
缓冲区描述符保存着页面的元数据,对应的页面则保存在缓冲池的槽位中。缓冲区描述符的结构由BufferDesc 结构定义。
/* src/include/storage/buf_internals.h (9.6版本之后, 移除了一些字段) */ /* 缓冲区描述符的标记位定义(9.6版本之后) * 注意,TAG_VALID实际上意味着缓冲区散列表中有一条与本tag关联的项目 */ #define BM_LOCKED (1U << 22) /* 缓冲区首部被锁定 */ #define BM_DIRTY (1U << 23) /* 数据需要写入 */ #define BM_VALID (1U << 24) /* 数据有效 */ #define BM_TAG_VALID (1U << 25) /* 标签有效,已经分配 */ #define BM_IO_IN_PROGRESS (1U << 26) /* 读写进行中 */ #define BM_IO_ERROR (1U << 27) /* 先前的I/O失败 */ #define BM_JUST_DIRTIED (1U << 28) /* 写之前已经脏了 */ #define BM_PIN_COUNT_WAITER (1U << 29) /* 有人等着钉住页面 */ #define BM_CHECKPOINT_NEEDED (1U << 30) /* 必须在检查点时写入 */ #define BM_PERMANENT (1U << 31) /* 永久缓冲 */ /* BufferDesc -- 单个共享缓冲区的共享描述符/共享状态 * * 注意,读写tag、state、wait_backend_pid 等字段时必须持有缓冲区首部锁(BM_LOCKED标记位) * 简单地说,refcount、usagecount标记位组合起来被放入一个原子变量state中,而缓冲区首部锁 * 实际上是嵌入标记位中的一个bit。这种设计允许我们使用单个原子操作,而不是获取/释放自旋锁 * 来实现一些操作。例如refcount的增减。buf_id字段在初始化之后再也不会改变,所以不需要锁 * freeNext是通过buffer_strategy_lock而非buf_hdr_lock来保护的。LWLocks字段可以自己管好自 * 己。注意,buf_hdr_lock *不是* 用来控制对缓冲区内数据的访问的 * * 我们假设持有首部锁时,没人会修改state字段。因此持有缓冲区首部锁的人可以在一次写入 * 中对state变量进行很复杂的更新,包括更新完的同时释放锁(清理BM_LOCKED标记位)。此外,不持有 * 缓冲区首部锁而对state进行更新仅限于CAS操作,它能确保操作时,没有设置BM_LOCKED标记位 * 不允许使用原子自增/自减、OR/AND等操作 * * 一个例外是,如果我们钉住了该缓冲区,它的标签除了我们自己之外不会被偷偷修改 * 所以我们无须锁定自旋锁就可以检视该标签。此外,一次性的标记读取也无须锁定自旋锁, * 当我们期待测试标记位不会改变时,这种做法很常见 * * 如果另一个后端钉住了该缓冲区,我们就无法从磁盘页面上物理移除项目。因此后端需要等待 * 所有其他的钉被移除。移除时它会得到通知,这是通过将它的PID存到wait_backend_pid,并设置 * BM_PIN_COUNT_WAITER标记位而实现的。就目前而言,每个缓冲区只能有一个等待者 * * 对于本地缓冲区,我们也使用同样的首部,不过锁字段就没用了,一些标记位也没用。为了避免不必要 * 的开销,对state字段的操作不需要用实际的原子操作(即pg_atomic_read_u32, * pg_atomic_unlocked_write_u32) * * 增加该结构的尺寸,增减、重排该结构的成员时需要特别小心。保证该结构体小于64B对于性能 * 至关重要(最常见的CPU缓存尺寸) */ typedef struct BufferDesc { BufferTag tag; /* 存储在缓冲区中页面的标识 */ int buf_id; /* 缓冲区的索引编号 (从0开始) */ /* 标记的状态,包含标记位、引用计数、使用计数 */ /* 9.6版本使用原子操作替换了很多字段的功能 */ pg_atomic_uint32 state; int wait_backend_pid; /* 等待钉页计数的后端进程PID */ int freeNext; /* 空闲链表中的链接 */ LWLock content_lock; /* 访问缓冲区内容的锁 */ } BufferDesc; /* before 9.6*/ typedef struct sbufdesc { BufferTag tag; /* 存储在缓冲区中页面的标识 */ BufFlags flags; /* 标记位 */ uint16 usage_count; /* 时钟扫描要用到的引用计数 */ unsigned refcount; /* 在本缓冲区上持有PIN的后端进程数 */ int wait_backend_pid; /* 等着PIN本缓冲区的后端进程PID */ slock_t buf_hdr_lock; /* 用于保护上述字段的锁 */ int buf_id; /* 缓冲的索引编号 (从0开始) */ int freeNext; /* 空闲链表中的链接 */ LWLockId io_in_progress_lock; /* 等待I/O完成的锁 */ LWLockId content_lock; /* 访问缓冲区内容的锁 */ } BufferDesc;
-
tag 保存着目标页面的buffer_tag,该页面存储在相应的缓冲池槽中。
-
buffer_id 标识了缓冲区描述符,亦相当于对应缓冲池槽的buffer_id。
-
refcount 保存当前访问相应页面的PostgreSQL进程数,也被称为钉数。当PostgreSQL进程访问相应页面时,其引用计数必须自增1(refcount ++)。访问结束后其引用计数必须减1(refcount–)。当refcount为零,即页面当前并未被访问时,页面将取钉,否则它会被钉住。
-
usage_count 保存着相应页面加载至相应缓冲池槽后的访问次数。usage_count会在页面置换算法中被用到。
-
context_lock 和 io_in_progress_lock 是轻量级锁,用于控制对相关页面的访问。
-
flags 用于保存相应页面的状态,主要状态如下:
- 脏位指明相应页面是否为脏页。
- 有效位指明相应页面是否可以被读写(有效)。例如,如果该位被设置为 “valid”,那就意味着对应的缓冲池槽中存储着一个页面,而该描述符中保存着该页面的元数据,因而可以对该页面进行读写。反之如果有效位被设置为 “invalid”,那就意味着该描述符中并没有保存任何元数据,即对应的页面无法读写,缓冲区管理器可能正在将该页面换出。
- IO进行标记位指明缓冲区管理器是否正在从存储中读/写相应页面。换句话说,该位指示是否有一个进程正持有此描述符上的 io_in_pregress_lock。
-
freeNext 是一个指针,指向下一个描述符,并以此构成一个空闲列表(freelist)。
为了简化后续章节的描述,这里定义三种描述符状态。
-
空:当相应的缓冲池槽不存储页面时,即 refcount 与 usage_count 都是0,该描述符的状态为空。
-
钉住:当相应缓冲池槽中存储着页面,且有 PostgreSQL 进程正在访问的相应页面时, 即 refcount和 usage_count 都大于等于1,该缓冲区描述符的状态为钉住。
-
未钉住:当相应的缓冲池槽存储页面,但没有PostgreSQL进程正在访问相应页面时,即 usage_count 大于或等于1,但 refcount 为0,该缓冲区描述符的状态为未钉住。每个描述符都处于上述状态之一。描述符的状态会根据特定条件而改变。
缓冲区描述符层
缓冲区描述符的集合构成了一个数组,本书称该数组为缓冲区描述符层。当 PostgreSQL 服务器启动时,所有缓冲区描述符的状态都为空。在 PostgreSQL中,这些描述符构成了一个名为 freelist 的链表,缓冲区管理器初始状态下图所示。
下图显示第一页的加载方式:
-
从freelist的头部取一个空描述符,并将其钉住,即将refcount和usage_count增加1。
-
在缓冲表中插入新项,该缓冲表项保存了页面buffer_tag与所获描述符buffer_id之间的关系。
-
将新页面从存储器加载至相应的缓冲池槽中。
-
将新页面的元数据保存至所获取的描述符中。
第二页和后续页面的加载方式类似。
从freelist中摘出的描述符始终保存着页面的元数据。换言之,仍然在使用的非空描述符不会返还到freelist中。但当下列任一情况出现时,描述符状态将变为“空”,并被重新插入至freelist中。
- 相关表或索引已被删除。
- 相关数据库已被删除。
- 相关表或索引已经被VACUUM FULL命令清理。
缓冲池
缓冲池只是一个用于存储关系数据文件(例如表或索引)页面的简单数组。缓冲池数组的序号索引也就是 buffer_id。
缓冲池槽的大小为 8KB,等于页面大小,因而每个槽都能存储整个页面。
缓冲区管理器锁
缓冲区管理器会出于不同的目的使用各式各样的锁,本节将介绍理解后续部分所必备的一些锁。
注意,本节描述的锁,指的是缓冲区管理器同步机制的一部分。它们与SQL语句和SQL操作中的锁没有任何关系。
缓冲表锁
缓冲表锁 BufMappingLock 保护整个缓冲表的数据完整性。它是一种轻量级的锁,有共享模式与独占模式。在缓冲表中查询条目时,后端进程会持有共享的 BufMappingLock。插入或删除条目时,后端进程会持有独占的BufMappingLock。BufMappingLock 会被分为多个分区,以减少缓冲表中的争用(默认为128个分区)。每个BufMappingLock 分区都保护着一部分相应的散列桶槽。
下图给出了一个 BufMappingLock 分区的典型示例。两个后端进程可以同时持有各自分区的 BufMappingLock 独占锁,以插入新的数据项。如果 BufMappingLock 是系统级的锁,那么其中一个进程就需要等待另一个进程完成处理。
缓冲表也需要许多其他锁。例如,在缓冲表内部会使用自旋锁(spin lock)来删除数据项。不过本章不需要这些锁的其他相关知识,因此这里省略了对其他锁的介绍。
缓冲区描述符相关的锁
每 个 缓 冲 区 描 述 符 都 会 用 到 内 容 锁(content_lock)与 IO 进 行 锁(io_in_progress_lock)这两个轻量级锁,以控制对相应缓冲池槽页面的访问。当检查或更改描述符本身字段的值时,就会用到自旋锁。
内容锁
内容锁(content_lock)是一个典型的强制限制访问的锁,它有共享与独占两种模式。当读取页面时,后端进程以共享模式获取页面相应缓冲区描述符中的 content_lock。执行下列操作之一时,则会获取独占模式的content_lock。
- 将行(即元组)插入页面,或更改页面中元组的 t_xmin/t_xmax 字段时。
- 物理移除元组,或压紧页面上的空闲空间(由清理过程和HOT执行)
- 冻结页面中的元组。
IO进行时锁
IO 进行锁(io_in_progress_lock)用于等待缓冲区上的I/O完成。当PostgreSQL进程加载/写入页面数据时,该进程在访问页面期间,持有对应描述符上独占的io_in_progres_lock。
自旋锁
自旋锁当检查或更改标记字段与其他字段时,例如 refcount和 usage_count,会用到自旋锁。
下面是两个使用自旋锁的具体例子。
- 钉住缓冲区描述符。
-
获取缓冲区描述符上的自旋锁。
-
将其refcount和usage_count的值增加1。
-
释放自旋锁
- 将脏位设置为"1"。
-
获取缓冲区描述符上的自旋锁。
-
使用位操作将脏位置位为"1"。
-
释放自旋锁。
缓冲区管理器的工作原理
本节介绍缓冲区管理器的工作原理。当后端进程想要访问所需页面时,它会调用ReadBufferExtended函数。函数 ReadBufferExtended 的行为因场景而异,在逻辑上具体可以分为三种情况。每种情况都将用一小节介绍。第四小节将介绍PostgreSQL中基于时钟扫描的页面置换算法。
访问存储在缓冲池中的页面
当从缓冲池槽中的页面里读取行时,PostgreSQL 进程获取相应缓冲区描述符的共享content_lock,因而缓冲池槽可以同时被多个进程读取。
当向页面插入(及更新、删除)行时,该 postgres后端进程获取相应缓冲区描述符的独占content_lock(注意,这里必须将相应页面的脏位置设为"1")。访问完页面后,相应缓冲区描述符的引用计数值减1。
我们来介绍最简单的情况,即所需页面已经存储在缓冲池中。在这种情况下,缓冲区管理器会执行以下步骤:
(1)创建所需页面的 buffer_tag(在本例中 buffer_tag 是’Tag_C’),并使用散列函数计算与描述符相对应的散列桶槽。
(2)获取相应散列桶槽分区上的 BufMappingLock 共享锁。
(3)查找标签为 ‘Tag_C’ 的条目,并从条目中获取 buffer_id。本例中 buffer_id 为2。
(4)将 buffer_id=2 的缓冲区描述符钉住,即将描述符的 refcount 和 usage_count 增加1。
(5)释放BufMappingLock。
(6)访问buffer_id=2的缓冲池槽。
将页面从存储加载到空槽
下图是将页面从存储加载到空槽的示意图:
在第二种情况下,假设所需页面不在缓冲池中,且 freelist 中有空闲元素(空描述符)。这时,缓冲区管理器将执行以下步骤:
(1)查找缓冲区表(本节假设页面不存在,找不到对应页面)。
- 创建所需页面的 buffer_tag(本例中 buffer_tag 为 ‘Tag_E’ )并计算其散列桶槽。
- 以共享模式获取相应分区上的 BufMappingLock。
- 查找缓冲区表(根据假设,这里没找到)。
- 释放 BufMappingLock。
(2)从 freelist 中获取空缓冲区描述符,并将其钉住。在本例中所获的描述符:buffer_id=4。
(3)以独占模式获取相应分区的 BufMappingLock(此锁将在步骤(6)中被释放)。
(4)创建一条新的缓冲表数据项:buffer_tag=‘Tag_E’, buffer_id=4,并将其插入缓冲区表中。
(5)将页面数据从存储加载至 buffer_id=4 的缓冲池槽中,如下所示:
-
以排他模式获取相应描述符的 io_in_progress_lock。
-
将相应描述符的 IO_IN_PROGRESS 标记位设置为1,以防其他进程访问。
-
将所需的页面数据从存储加载到缓冲池插槽中。
-
更改相应描述符的状态,将 IO_IN_PROGRESS 标记位设置为"0",且 VALID 标记位设置为"1"。
-
释放 io_in_progress_lock。
(6)释放相应分区的 BufMappingLock。
(7)访问 buffer_id=4 的缓冲池槽。
将页面从存储加载到受害者缓冲池槽
在这种情况下,假设所有缓冲池槽位都被页面占用,且未存储所需的页面。下面两个图是将页面从存储加载到受害者缓冲池槽的示意图。
缓冲区管理器将执行以下步骤:
(1)创建所需页面的 buffer_tag 并查找缓冲表。在本例中假设 buffer_tag 是 ‘Tag_M’ (且相应的页面在缓冲区中找不到)。
(2)使用时钟扫描算法选择一个受害者缓冲池槽位,从缓冲表中获取包含着受害者槽位 buffer_id 的旧表项,并在缓冲区描述符层将受害者槽位的缓冲区描述符钉住。本例中受害者槽的 buffer_id=5,旧表项为 Tag_F, id = 5。时钟扫描将在下一节介绍。
(3)如果受害者页面是脏页,则将其刷盘(write & fsync),否则进入步骤(4)。
在使用新数据覆盖脏页之前,必须将脏页写入存储中。脏页的刷盘步骤如下:
1. 获取 buffer_id=5 描述符上的共享 content_lock 和独占 io_in_progress_lock。 2. 更改相应描述符的状态:相应 IO_IN_PROCESS 位设置为"1",JUST_DIRTIED 位设置为"0"。 3. 根据具体情况,调用 XLogFlush() 函数将WAL缓冲区上的WAL数据写入当前WAL段文件(WAL和XLogFlush函数将在第9章中介绍)。 4. 将受害者页面的数据刷盘至存储中。 5. 更改相应描述符的状态;将 IO_IN_PROCESS 位设置为"0",将 VALID 位设置为"1"。 6. 释放 io_in_progress_lock和 content_lock。
以排他模式获取缓冲区表中旧表项所在分区上的 BufMappingLock。
(5)获取新表项所在分区上的 BufMappingLock,并将新表项插入缓冲表:
-
创建新表项:由 buffer_tag='Tag_M’与受害者的 buffer_id组成的新表项。
-
以独占模式获取新表项所在分区上的 BufMappingLock。
-
将新表项插入缓冲区表中。
(6)从缓冲表中删除旧表项,并释放旧表项所在分区的 BufMappingLock。
(7)将目标页面数据从存储加载至受害者槽位,然后用 buffer_id=5 更新描述符的标识字段,将脏位设置为0,并按流程初始化其他标记位。
(8)释放新表项所在分区上的 BufMappingLock。
(9)访问 buffer_id=5 对应的缓冲区槽位。
页面替换算法:时钟扫描
本节的其余部分介绍了时钟扫描算法。该算法是NFU(Not Frequently Used)算法的变体,开销较少,能高效地选出较少使用的页面。我们将缓冲区描述符想象为一个循环列表,如下图所示,缓冲区描述符为黑色或灰色的方框,框中的数字显示每个描述符的 usage_count。而 nextVictimBuffer是一个 32位的无符号整型变量,它总是指向某个缓冲区描述符并按顺时针顺序旋转。
时钟扫描的伪代码如下:
WHILE true (1) 获取nextVictimBuffer指向的缓冲区描述符 (2) IF 缓冲区描述符没有被钉住 THEN (3) IF 候选缓冲区描述符的 usage_count == 0 THEN BREAK WHILE LOOP /* 该描述符对应的槽就是受害者槽 */ ELSE 将候选描述符的 usage_count - 1 END IF END IF (4) 迭代 nextVictimBuffer,指向下一个缓冲区描述符 END WHILE (5) RETURN 受害者页面的 buffer_id
该算法的伪代码与算法描述如下:
-
nextVictimBuffer 指向第一个描述符(buffer_id = 1),但因为该描述符被钉住了,所以跳过。
-
nextVictimBuffer 指向第二个描述符(buffer_id = 2),该描述符未被钉住,但其 usage_count 为2,因此该描述符的 usage_count 将减1,而 nextVictimBuffer 迭代至第三个候选描述符。
-
nextVictimBuffer 指向第三个描述符(buffer_id = 3),该描述符未被钉住,但其 usage_count = 0,因而成为本轮的受害者。
当 nextVictimBuffer 扫过未钉住的描述符时,其 usage_count 会减1。因此只要缓冲池中存在未钉住的描述符,该算法总能在旋转若干次 nextVictimBuffer 后,找到一个 usage_count 为 0 的受害者。这样做的好处就是能够优先利用usage_count小的页面。
环形缓冲区
在读写大表时,PostgreSQL 会使用环形缓冲区而不是缓冲池。环形缓冲器是一个很小的临时缓冲区域。当满足下列任一条件时,PostgreSQL 将在共享内存中分配一个环形缓冲区:
-
批量读取。当扫描关系读取数据的大小超过缓冲池的四分之一时,环形缓冲区的大小为 256 KB。
-
批量写入,当执行下列 SQL 命令时,环形缓冲区大小为 16 MB。
-
COPY FROM 命令。
-
CREATE TABLE AS 命令。
-
CREATE MATERIALIZED VIEW 或 REFRESH MATERIALIZED VIEW 命令。
-
ALTER TABLE 命令。
-
-
清理过程,当自动清理守护进程执行清理过程时,环形缓冲区大小为 256 KB。分配的环形缓冲区将在使用后被立即释放。
环形缓冲区的好处显而易见,如果后端进程在不使用环形缓冲区的情况下读取大表,则所有存储在缓冲池中的页面都会被移除,这会导致缓存命中率降低。环形缓冲区可以避免此问题。
为什么批量读取和清理过程的默认环形缓冲区大小为 256 KB? 源代码中缓冲区管理器目录下的 README 中解释了这个问题。顺序扫描使用 256KB 的环形缓冲区, 它足够小,因而能放入L2缓存中,从而使得操作系统缓存到共享缓冲区的页面传输变得高效。 通常更小一点也可以,但环形缓冲区需要足够大到能同时容纳扫描中被钉住的所有页面。
脏页刷盘
除了置换受害者页面之外,检查点进程和后台写入器进程也会将脏页刷盘至存储中。尽管两个进程都具有相同的功能(脏页刷盘),但是它们有着不同的角色和行为。
检查点进程将检查点记录写入WAL段文件,并在检查点开始时进行脏页刷盘。
后台写入器的目的是通过少量多次的脏页刷盘,减少检查点带来的密集写入的影响。后台写入器会一点点地将脏页落盘,尽可能减少对数据库活动造成的影响。在默认情况下,后台写入器每 200ms 被唤醒一次(由参数 bgwriter_delay 定义),且最多刷写 bgwriter_lru_maxpages个页面(默认为100个页面)。
为什么检查点进程与后台写入器相分离? 在 9.1及更低版本中,后台写入器会规律性地执行检查点进程。在 9.2版本中,检查点进程从后台写入被单独 剥离出来。原因在一篇题为“将检查点进程与后台写入器相分离”的提案中有介绍。 下面是一些摘录:当前(在 2011年)后台写入器进程既执行后台写入,又负责检查点,还处理一些其他的职责。 这意味着我们没法在不停止后台写入的情况下执行检查点最终的fsync。因此,在同一个进程中做两件事会有负面 的性能影响。此外,在9.2版本中,我们的一个目标是通过将轮询循环替换为锁存器,从而降低功耗。 bgwriter中的循环复杂度太高了,以至于无法找到一种简单的使用锁存器的方法。
本文翻译整理自:
https://www.interdb.jp/pg/pgsql08.html
这篇关于《postgresql指南--内幕探索》第八章 缓冲区管理的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-01-05快速清空 PostgreSQL 数据库中的所有表格,让你的数据库重新焕然一新!
- 2024-01-04在PostgreSQL中创建角色:判断角色是否存在并创建
- 2023-05-16PostgreSQL一站式插件推荐 -- pg_enterprise_views
- 2022-11-22PostgreSQL 实时位置跟踪
- 2022-11-22如何将PostgreSQL插件移植到openGauss
- 2022-11-11PostgreSQL:修改数据库用户的密码
- 2022-11-06Windows 环境搭建 PostgreSQL 物理复制高可用架构数据库服务
- 2022-10-27Windows 环境搭建 PostgreSQL 逻辑复制高可用架构数据库服务
- 2022-10-11PostgreSql安装(Windows10版本)
- 2022-09-13PostgreSQL-Network Address类型操作和函数