当前位置:首页 > 报告详情

1-增量检查点的“困”与“难”-吕海波.pdf

上传人: S** 编号:1240961 2026-05-16 54页 3.62MB

1、增量检查点的增量检查点的“困困”与与“难难”吕海波易景科技首席研究员PG ACED 北京大学企业导师 开源生态大会暨开源生态大会暨PostgreSQLPostgreSQL高峰论坛高峰论坛以开源之道见致远之志TAC TAC 共享存储集群与增共享存储集群与增量检查量检查点ckptqckptq 共享内存锁管理共享内存锁管理机制机制增量检查增量检查点与与 FPWFPW目录CONTENTS开源生态大会暨开源生态大会暨PostgreSQLPostgreSQL高峰论坛高峰论坛以开源之道见致远之志TAC(True Application Cluster)TAC(True Application Cluster

2、)共享存储集群共享存储集群开源生态大会暨开源生态大会暨PostgreSQLPostgreSQL高峰论坛高峰论坛以开源之道见致远之志联接层HSM 存储层计算层计算层应用层增量检查增量检查点开源生态大会暨开源生态大会暨PostgreSQLPostgreSQL高峰论坛高峰论坛以开源之道见致远之志 核心思想核心思想:增加 ckptq(检查点队列),按块变脏顺序,排列所有脏块沿 ckptq 写脏块 分享两个关键点分享两个关键点:ckptq 共享内存锁管理机制Full Page Write的处理ckptqckptq 共享内存锁管理机制共享内存锁管理机制开源生态大会暨开源生态大会暨PostgreSQLPos

3、tgreSQL高峰论坛高峰论坛以开源之道见致远之志 自璇锁从Lock-Free编程,到Latch/Mutex,自璇锁无处不在。PG中的自璇锁:s_lock()SpinLockInit()SpinLockAcquire()SpinLockRelease()SpinLockFree()自璇的目的不自璇,无法得到锁,就要被设为Sleep状态,让出CPU。自璇可以霸占CPU,避免换出CPU后,Cache被其他进程污染。0Sess 1Sess 21Sess 1 加锁成功Sess 2 检查锁值,非零,锁已被其他进程持有Sess 2 循环重复检查锁值,直到锁值为0(或循环一定次数),称为自璇。ckptqck

4、ptq 共享内存锁管理机制共享内存锁管理机制开源生态大会暨开源生态大会暨PostgreSQLPostgreSQL高峰论坛高峰论坛以开源之道见致远之志 自璇锁竞争时的问题当某一锁遭遇竞争,多个进程同时自璇时,会导致一个严重问题。下面将视角切换到CPU。0Sess 1Sess 21Sess 2 循环重复检查锁值,直到锁值为0(或循环一定次数),称为自璇。Sess 3Sess 4Sess nckptqckptq 共享内存锁管理机制共享内存锁管理机制开源生态大会暨开源生态大会暨PostgreSQLPostgreSQL高峰论坛高峰论坛以开源之道见致远之志 从CPU角度观察Core 0 持有Lock当Co

5、re 0 释放锁时,修改锁变量为0Core 0Core 1Core 2Core 3Core 4Core 5Core 6Core 7Core 8Core 9Core 10Core 11Core 12Core 13Core 14Core 151ckptqckptq 共享内存锁管理机制共享内存锁管理机制开源生态大会暨开源生态大会暨PostgreSQLPostgreSQL高峰论坛高峰论坛以开源之道见致远之志 从CPU角度观察Core 0 持有Lock当Core 0 释放锁时,修改锁变量为0但是另外15个Core不断在读此变量的值,Core 0要广播一个Invalite 消息给另外15个Core。之后,

6、才能修改锁变量为0Core 0Core 1Core 2Core 3Core 4Core 5Core 6Core 7Core 8Core 9Core 10Core 11Core 12Core 13Core 14Core 151 0ckptqckptq 共享内存锁管理机制共享内存锁管理机制开源生态大会暨开源生态大会暨PostgreSQLPostgreSQL高峰论坛高峰论坛以开源之道见致远之志 从CPU角度观察Core 0 持有Lock当Core 0 释放锁时,修改锁变量为0但是另外15个Core不断在读此变量的值,Core 0要广播一个Invalite 消息给另外15个Core。之后,才能修改锁变

word格式文档无特别注明外均可编辑修改,预览文件经过压缩,下载原文更清晰!
三个皮匠报告文库所有资源均是客户上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作商用。
1. **增量检查点核心机制**:通过引入`ckptq`检查点队列,按块变脏顺序排列脏块并写入,解决传统检查点效率问题。 2. **自旋锁竞争问题**:多核环境下自旋锁导致CPU缓存频繁失效,改进方案为各核心独立自旋变量,减少同步开销。 3. **Partial Writes处理对比**: - **Oracle**:依赖介质恢复,不解决页分裂问题,需手动`BlockRecover`。 - **MySQL**:采用Double Write Buffer机制,避免页分裂但未根治。 - **PostgreSQL**:通过Full Page Writes(FPW)彻底解决Partial Writes,但性能代价较高。 4. **测试验证**:模拟I/O中断(如`pwrite`截断),PG自动恢复数据,Oracle/MySQL需人工干预。
**锁竞争困局** (聚焦自旋锁在多核环境下的性能瓶颈,吸引对数据库内核优化感兴趣的读者) **页分裂之谜** (以“谜”引发好奇,探讨Partial Writes问题及各数据库的应对策略,吸引数据库架构师) **FPW代价** (直指PostgreSQL解决方案的核心痛点,吸引关注性能与可靠性平衡的开发者)
客服
商务合作
小程序
服务号
折叠