乔宾·奥古斯丁：使用Linux cgroup2控制PostgreSQL服务器的资源消耗
内容提要
多租户/共托是挑战性任务，运行多个PG实例可减少PostgreSQL内部争用点。Linux的cgroups可控制资源消耗，cgroup2是cgroup版本一的替代品。创建单独的slice用于PostgreSQL实例可更好地控制资源消耗。控制组是限制机器资源消耗的有效方法，cgroup2使其更简单易用。
延伸解读
cgroup2 的启用条件与检查方法
文章指出，要可靠使用 cgroup2，Linux 内核版本需为 5.2.0 或更高。对于 2022 年及之后发布的发行版，通常已默认启用。检查当前系统使用的是 cgroup v1 还是 v2，可通过统计 /proc/mounts 中 cgroup 的挂载数量：若结果为 1，则为 cgroup2；若为多个，则仍是 v1。若内核较新但仍使用 v1，可添加内核启动参数 systemd.unified_cgroup_hierarchy=1 并重启。
为 PostgreSQL 实例创建独立 slice 的实践
当一台机器上运行多个 PostgreSQL 实例时，为它们创建单独的 slice 有助于从更高层级控制整体资源消耗。文章演示了通过 systemctl edit --force postgres.slice 创建 slice，并在其中设置 MemoryLimit、CPUQuota 等参数。随后在 PostgreSQL 服务的 unit 文件中通过 Slice=postgres.slice 将其纳入该 slice。重启服务后，可用 systemd-cgls 或 systemctl status 验证 PostgreS
资源限制的效果与权衡
文章通过一个单 CPU 机器的基准测试展示了 cgroup 限制的实际效果：无论施加多大压力，PostgreSQL 的总 CPU 使用率都被限制在 slice 中设定的 25% 左右（各进程相加约为 24.9%）。作为对比，无 cgroup 限制的相同工作负载可使服务器 CPU 达到 100% 利用率。作者也明确指出，cgroup 限制会降低吞吐量，这是预期内的权衡。
服务级控制与多租户场景的价值
如果主机上只有一个 PostgreSQL 实例，可以不创建独立 slice，而是直接在服务 unit 的 [Service] 段中设置 CPUQuota 等资源控制参数，更改在下次重启后生效。文章认为，清晰的资源控制能改善多租户环境，防止“吵闹邻居”效应；同时可避免系统过载导致所有程序无响应，进而引发 HA 框架不必要的故障转移。此外，应用与数据库共置时可通过本地套接字通信，避免网络成为性能瓶颈。
Q&A
什么是Linux cgroup2，它有什么优势？
Linux cgroup2是控制组的第二个版本，简化了资源控制，适用于Linux内核版本5.2.0或更高版本，解决了版本一的许多限制。
如何检查Linux系统使用的cgroup版本？
可以通过查看挂载数量来判断，使用命令`grep -c cgroup /proc/mounts`，如果返回1，则表示使用的是cgroup2。
如何为PostgreSQL实例创建单独的slice？
可以使用命令`sudo systemctl edit --force postgres.slice`来创建slice，并在配置中设置资源限制。
使用cgroup2对PostgreSQL服务进行资源控制有什么好处？
使用cgroup2可以限制PostgreSQL的CPU和内存使用，防止资源争用，改善多租户环境，避免“吵闹邻居”效应。
如何在PostgreSQL服务中应用slice？
在PostgreSQL服务的unit文件中添加`Slice=postgres.slice`配置，然后重启服务以应用新的slice。
cgroup2如何改善多租户环境？
cgroup2通过限制每个租户的资源使用，防止它们之间的资源竞争，从而改善多租户环境的性能。
