使用 Linux cgroup2 控制 PostgreSQL 服务器的资源消耗
内容提要
多租户/共托是挑战性任务，运行多个PG实例可减少内部争用点，但可能导致吵闹的邻居效应。Linux的cgroups可控制资源消耗，cgroup2是版本一的替代品，解决了限制。创建单独的slice用于PostgreSQL实例是好主意，可从更高层次控制资源消耗。cgroup2非常灵活，是限制资源消耗的经过验证的方法。
延伸解读
cgroup2 的启用前提与检查方法
文章指出，可靠使用 cgroup2 需要 Linux 内核 5.2.0 或更高版本，2022 年后的发行版通常已支持。检查当前系统是否使用 cgroup2，可运行 grep -c cgroup /proc/mounts，若结果为 1 则表明是 cgroup2；若内核较新但仍使用 cgroup1，可通过添加内核启动参数 systemd.unified_cgroup_hierarchy=1 并重启来启用。
为 PostgreSQL 实例创建独立 slice 的实践
当主机运行多个 PostgreSQL 实例时，文章建议创建单独的 slice 以便从更高层次控制资源。示例中通过 systemctl edit --force postgres.slice 创建 slice，并设置 MemoryLimit=2048M、CPUQuota=25%、TasksMax=4096 等限制。随后在 PostgreSQL 服务单元中添加 Slice=postgres.slice，重启服务后实例即运行在该 slice 下。
单实例场景下的服务级资源控制
如果主机上只有一个 PostgreSQL 实例，文章认为不必单独创建 slice，可直接在服务单元中指定资源限制。例如在 [Service] 段添加 CPUAccounting=true 和 CPUQuota=25%，重启后生效。这种方式更简单，适合单实例部署，同时仍能防止 PostgreSQL 过度消耗 CPU。
资源控制的实际效果与注意事项
文章通过实验验证，在单核机器上对 PostgreSQL 施加 cgroup 限制后，其总 CPU 利用率被控制在约 24.9%，而未限制时可达 100%。限制会降低吞吐量，这是预期内的权衡。此外，良好的资源控制有助于避免系统过载导致的服务拒绝和不必要的故障转移，并改善多租户环境中的吵闹邻居效应。
Q&A
什么是cgroup2，它与cgroup1有什么不同？
cgroup2是Linux控制组的第二个版本，解决了cgroup1的许多限制，提供了更灵活的资源管理方式。
如何检查Linux系统使用的cgroup版本？
可以通过查看/proc/mounts中的挂载数量来检查，若数量为1则表示使用cgroup2。
在PostgreSQL中如何创建和管理资源限制？
可以通过systemctl命令创建PostgreSQL的slice，并在服务单元中指定资源限制。
使用cgroup2对多租户环境有什么好处？
cgroup2可以防止“吵闹的邻居”效应，确保不同租户之间的资源竞争得到控制。
如何在PostgreSQL服务中应用cgroup限制？
在PostgreSQL服务的单元文件中添加Slice=postgres.slice配置，并重启服务以应用限制。
cgroup2如何改善系统的资源使用控制？
cgroup2提供了更简单的资源使用控制方法，能够有效防止系统过载和服务拒绝。
