PostgreSQL@K8s 性能优化记

近年来，很多企业的基础架构都有计划 all-in-K8s 的计划，希望采用基于 K8s 的数据库管控平台（如 KubeBlocks^[1]——《给你介绍一个有趣的开源项目 - KubeBlocks》）作为自建 PostgreSQL 托管方案（下文以 KubeBlocks-PG 为例）。此外，数据库的容器化和 K8s 化是比较新的话题，很多人对有状态应用上 K8s 抱有比较大的怀疑态度，我们希望验证数据库在 K8s 上性能是否能满足生产要求。本文提供在公有云 ECS 上自建 PostgreSQL（下文中以 ECS PG 代指）和基于 K8s 的数据库管控平台作为自建 PostgreSQL 托管方案进行对比，并提出如何在 K8s 上优化 PG 性能的方案。

‍‍‍‍

1. 在云厂商托管的 ACK 服务上购买 K8s 集群并部署 KubeBlocks^[2]，网络模式采用 Terway，Terway 生产出来的 Pod IP 为 VPC IP，保证一个 VPC 内的网络可达，简化了网络管理和应用开发的成本，node 的规格为 16C64G。
2. 生产实例：一开始在独占的 node 上无法生产出 16C64G 的规格，因为 kubelet 等 agent 还消耗部分资源，所以调低 request 和 limit 到 14C56G 后生产成功。

使用 kubectl edit 编辑 pg cluster 的 resource spec，去掉对 request 和 limit 的限制，保证压测过程中可以使用到 16C CPU，buffers 设置为 16GB，创建 PG 实例：

Sysbench Read-intensive 测试：80% read + 20% write。

该测试场景读多写少，比较接近实际的生产场景。

从 ECS 压测机发起压测，通过 VPC IP 访问 PG。

发现三个问题：

1. CPU 无法打满：从 ECS 压测 DB，DB 所在 node CPU 无法压满。
2. 并发衰减快：随着压测并发数上升，KubeBlocks PG 性能衰减要比 ECS PG 快。
3. TPS 间歇性跌 0：在压测的过程中经常出现间歇性的 TPS 跌 0（307s 开始）。

此时因为 client 和 server 端的 CPU 都无法压满，所以怀疑是中间的网络链路有问题，尤其是怀疑 SLB 的规格是否到达上限，所以把 SLB 规格换成了 slb.s3.large 重新压测，ACK SLB 的默认规格是  slb.s2.small。

换成 slb.s3.large 之后继续压测，问题依然存在。

针对 SLB 延迟设计测试 case，使用 sysbench select 1 来模拟全链路网络延迟，单纯的 ping 测试虽然也能反映部分网络延迟，但是存在很多缺陷，而且不能保证刺穿全链路，比如 SLB 设备对 ping 产生的 ICMP 报文会直接返回，导致 SLB 到 Pod 的后续链路无法被探测到。

测试的发起端依然是 ECS，测试场景为： 

1. ECS -> Pod IP 使用 VPC 访问，网络可直达。

2. ECS -> SLB IP -> Pod IP 中间多了一层 SLB。

3. ECS -> ECS SLB IP ECS 默认在 PG 前端内置了一层 SLB。
   
   

测试结果如下：

结果说明 ACK 和 SLB 的网络都是正常的，性能波动的概率不大，所以对 SLB 的怀疑基本可以排除。

还是按照第一轮计划进行压测，这次从系统分析入手定性分析，查看云监控的 ECS 主机监控图。

发现两个现象：

1. 磁盘读写带宽达到了对应规格的瓶颈，ESSD 带宽和磁盘容量正相关，具体计算公式为：min{120+0.5*容量, 350}，300GB 磁盘对应的带宽为 270MB，从监控上看基本达到了瓶颈。
2. 通过排查日志发现，在 TPS 跌 0 的时间点 CPU 使用率也有对应的下跌。

由于之前磁盘带宽到达了上限，所以针对 IO 带宽又加了一组测试，测试 500GB 磁盘的表现情况，500GB 磁盘对应的带宽为 min{120+0.5*500, 350} = 350MB，压测过程中发现在磁盘跑满的时候，CPU 依然有锯齿状波动，根据以往经验，这种抖动可能和 checkpoint 有关，但是也不至于到跌 0 的地步。

在不断增加磁盘带宽的过程中发现 TPS 跌 0 的现象得到缓解，因此针对这个发现一次性把磁盘带宽调到最高，换成 ESSD PL2 1TB 磁盘，对应带宽 620MB，从图上看抖动依然存在，但得到很大缓解，CPU 使用率跌幅收窄。

再激进一点，直接升级到了 ESSD PL3 2TB，磁盘带宽达到 700MB。

TPS 跌 0 基本缓解，但是依然有比较大的抖动，TPS 从 2400 到 1400，跌幅差不多 40%，CPU 抖动幅度收窄但依然存在（@8183s）。

这一轮测试的结论就是 IO 带宽对 CPU 和 TPS 的影响很大，随着 IO 带宽的增加抖动幅度不断减少，TPS 跌 0 的问题消失，但是即使 IO 带宽不做限制，TPS 依然有 40% 的下跌抖动，在排除了硬件的瓶颈约束之后，这种抖动只可能和 PG 本身有关。

这次把目光聚焦到 Checkpoint 上来，主要是把传导机制搞清楚，分析 IO 限流是如何反馈到 Checkpoint 和事务的：

1. PostgreSQL Checkpoint 为何比其他数据库冲击要大？之前也测了一下 MySQL，发现 MySQL 在做 Checkpoint 时抖动相对要小很多。
2. 即使 IO 限流，但是从监控看 IO 还是满的，事务不应该跌 0，是不是此时带宽都被 Checkpoint 占用了？为了更好地监控数据库和主机指标，打开 KubeBlocks 集成的 Node Exporter 监控。

再一次压测，发现跌 0 的时候有一次比较大的内存回收，内存一次性被回收了 10GB，这个量有点大，在不开 Huge Page 的时候，一个 page frame 4KB，10GB 大概是 2.5MB 的 page 数量，大量 page 的遍历和回收对 os kernel page reclaim 模块会有很大的压力，而且在那个时间点上 os 卡了几十秒，导致上面的进程也都 hang 住，这种回收一般和 dirty_background_ratio 设置不合理有关，具体原理不再赘述。

执行sysctl -a | grep dirty_background_ratio，发现 vm.dirty_background_ratio = 10。

调整 background ratio 为 5%：sysctl -w vm.dirty_background_ratio=5。

这个调整会让一些脏掉的 page cache 尽早刷下去，这个比例设置之所以关键，和 PostgreSQL 的实现有很大关系，PostgreSQL 依赖 os page cache，与 Oracle、MySQL 这些数据库的 IO 架构不同。MySQL 使用 DirectIO，不依赖系统 page cache，给内存管理模块带来的压力和反过来受到的影响会小很多，当然某些场景下 DirectIO 延迟比写 buffer cache 会更大一些。

此时也开始关注 PostgreSQL 内核实现和日志，登录到 Pod 中，有如下发现：一个 WAL 日志默认大小为 16MB。

压测过程中，PostgreSQL 后台进程会清理 pg_wal 目录下的 WAL 日志以腾出空间，通过 strace 发现最多一次删除了几百个文件，总计大小 12GB（日志中的时间都要 +8 个时区，所以 5:42 对应北京时间 13:42）：

可以看到，做 Checkpoint 的一瞬间，cpu idle 就飙涨到了 80%（对应 TPS 基本跌 0）。

TPS 跌 0 也在 13:44:20 这个时间点结束。

13:45:41 开始做 vacuum。

13:47:04 checkpoint 真正完成。

整个过程的监控图：

发现 CPU busy 抖动和 Checkpoint 刷脏过程基本吻合。

全过程磁盘带宽一直打满：

跌 0 的时间段和 checkpoint 刷脏时间段基本一致：通过看内存的波动情况，发现内存回收导致的 hang 基本被消除，说明之前 dirty_background_ratio 的参数调整有效。

此外还发现，在刷脏过程中，锁的数量一直比较高，与非刷脏状态下的对比非常明显：

具体的锁有：

有时多个进程会抢同一把锁：

而且发现平时做 IO 的时候，磁盘带宽虽然会打满，但是事务之间很少抢锁，TPS 也不会跌 0，当锁竞争比较明显的时候，就很容易跌0，而锁的竞争又和 Checkpoint 直接相关。

1. stat(pg_wal/00000010000002F200000093) 找不到文件
2. 使用 pg_wal/xlogtemp.129 来创建
3. 清零 pg_wal/xlogtemp.129
4. 建立软连接 link("pg_wal/xlogtemp.129", "pg_wal/00000010000002F200000093")
5. 打开 pg_wal/00000010000002F200000093
6. 在尾部写入元数据
7. 加载并应用该 WAL 文件

查看 PostgreSQL 日志发现，那个时刻客户端有链接被重置，有的事务执行超过 10s。 

通过对比日志发现每次 WAL segment 耗时较长时，客户端就会产生一批慢查询（>1s）日志 PG 内核中清零的具体实现为：

从代码中可以看出 WAL 清零操作是先做异步写，每次写一个 page block，直到循环写完，然后再一次性做 fsync，异步写一般很快，当系统负载很低的时候，异步写 8KB 的数据响应时间是 us 级别，当系统负载比较重的时候，一个异步 IO 延迟甚至能达到 30ms+，异步写时延变长和 os kernel 的 io path 有很大关系，当内存压力大时，异步写可能会被 os 转成同步写，而且 IO 过程和 page reclaim 的 slowpath 交织在一起，所以理论上就有可能耗时很久，在实际 trace 中也确实如此。下面是监测到的紧邻的两次 WAL 清零 IO 操作，可以看到两次异步 IO 操作的间隔达到了 30ms+。

当时的磁盘带宽：

我们可以测算一下，对于一个 16MB 的 WAL segment，需要 2K 次清零操作，如果每次操作耗时 1ms，那么需要至少 2s 来能完成整体清零。

以某个正在执行的事务为例子：trace 一个正在执行事务的 PostgreSQL Backend 进程，中间等锁耗时 1.5s

对应的 SQL 是：

至此基本可以确定 Checkpoint 时 TPS 跌 0、CPU 抖动和 WAL 清零有关，具体传导机制是：

WAL 创建 -> WAL 清零 -> 刷脏和清零操作 IO 争抢 -> 事务等待变长 -> 持有锁时间变长 -> 被堵塞的事务进程越来越多 -> 事务大面积超时。

清零的最大问题是会产生大量 IO，并且需要所有事务挂起等待清零数据 sync 完成，直到新的 WAL 文件 ready，在这个过程中所有事务都要等待 WALWrite 和 wal_insert 锁，这是抖动的最大根源。不过问题的本质还是 IO 争抢，如果 IO 负载很低，清零速度比较快，观测到的抖动也不明显，问题也不会暴露，目前观测到的剧烈抖动也只出现在压测过程中，所以前面几轮测试中放大 IO 带宽也有助于缓解 TPS 跌 0 和 CPU 抖动。

由于在创建新的 WAL 文件的时候需要加锁，所以通过调整 WAL 文件大小来降低加锁的频率也是优化方向之一。

问题定位后，解决方案也就比较好找了，WAL 日志清零和判断 WAL 日志槽是否正常有关，本质上是一种不良好但比较省力的实现，最好的解决方案应该是 WAL 日志能自解释，不依赖清零来保证正确性，这种方案需要修改 PG 内核，所以不大现实；还有一种方案是虽然还需要清零，但是可以由文件系统来完成，不需要 PG 内核显式调用，当然这需要文件系统支持该清零特性。

ZFS 和 XFS 正好具备这个特性^[3] 。我们当前测试使用的 EXT4 并不具备这个特性，所以我们先尝试把文件系统改为 ZFS。

但是在测试 ZFS 的过程中，发现了好几次文件系统挂起的情况：

因此基于稳定性的考虑，ZFS 被暂时搁置，转而采用 XFS，并 set wal_init_zero = OFF，同时为了降低 WAL 日志文件创建的频率，我们把 wal_segment_size 从 16MB 调整到了 1GB，这样加锁频率也会降低。

经过测试，跌 0 和 CPU 抖动缓解很明显：

虽然消除清零操作和降低加锁频率能解决部分抖动问题，但是由于 Checkpoint 时刷脏和事务写 WAL 日志依然会抢带宽、抢锁，所以在 Checkpoint 时抖动依然存在，只是和之前相比有了很大的缓解，所以如果再继续优化，只能从降低单个事务的 IO 量上入手。

为了数据安全考虑，之前的压测都开启了 full_page_write，该特性用来保证断电时 page block 数据损坏场景下的数据恢复，具体原理可以参考《PG.特性分析.full page write 机制》（http://mysql.taobao.org/monthly/2015/11/05/），如果存储能保证原子写（不会出现部分成功、部分失败的情况）或 PG 能从某个备份集中恢复（正确的全量数据+增量WAL回放），那么在不影响数据安全的前提下可以尝试关闭 full_page_write。

关闭 full_page_write 前后 CPU 和 IO 带宽对比都非常明显：

可以看出 IO 争抢对 PG 的影响很大，而且在关闭 full_page_write 之后即使有 Checkpoint，CPU 也几乎没有抖动。

又加测了三种场景：

1. 开启 full_page_write+16MB WAL segment size；
2. 开启 full_page_write+1GB WAL segment size；
3. 关闭 full_page_write+1GB WAL segment size。

可以看出，在开启 full_page_write 时 1GB segment 比 16MB segment 表现要略好，也印证了通过增加 segment size 降低加锁频率的方案可行；关闭 full_page_write 后 PG 表现非常顺滑。

所以最终选择了一组 (wal_init_zero off + XFS) + (full_page_write off) + (wal_segment_size 1GB) 的组合测试，效果如下：

可以看到在 Checkpoint 时抖动消失，系统非常顺滑，PG 也从 IO-Bound 变成了 CPU-Bound，此时的瓶颈应该在 PG 的内部锁机制上。

不过根据以往的经验，PG 因为是进程模型，一个会话对应一个进程，当并发数比较高的时候，页表和进程上下文切换的代价会比较高，所以又引入了 pgBouncer；用户自建 ECS PG 为了解决并发问题，开启了 Huge Page，KubeBlocks PG 因为部署在 ACK 上，所以没有开启 Huge Page。

对比时为了公平，KubeBlocks 在下面的测试中开启了 full_page_write。

可以看出在引入 pgBouncer 之后，PG 能够承载更多的链接数而不会引起性能退化，KubeBlocks PG 比 PG 在性能上相差不大，在并发数比较低的时候性能上略好一些，整体稳定性上会更好一些。

1. WAL 清零对 PG 的性能和稳定性都有比较大的影响，如果文件系统支持清零特性，可以关闭 wal_init_zero 选项，可有效降低 CPU 和 TPS 抖动。
2. full_page_write 对 PG 的性能和稳定性也有比较大的影响，如果能从存储或备份上能保证数据的安全性，可以考虑关闭，可有效降低 CPU 和 TPS 抖动。
3. 增加 WAL segment size 大小，可降低日志轮转过程中加锁的频率，也可以降低 CPU 和 TPS 抖动，只是效果没那么明显。
4. PG 是多进程模型，引入 pgBouncer 可支持更大的并发链接数，并大幅提升稳定性，如果条件允许，可以开启 Huge Page，虽然原理不同，但效果和 pgBouncer 类似。
5. PG 在默认参数下，属于 IO-Bound，在经过上述优化后转化为 CPU-Bound。
6. ACK 和 SLB 网络实现比较健壮，性能和稳定性上都满足要求。
7. 在 K8s 上对文件系统、PG 参数等选项的调整非常方便，可以快速有效进行不同的组合测试，而且数据库跑在 K8s 上不会带来性能上的损耗，在做过通用调优之后可以达到很好的效果，对用户来说限制更少，有更强的自主性。

参考资料