GaussDB(DWS)的cgroup常见问题处理

一、概述

在上一篇博客中，我们介绍了GaussDB(DWS)实现CPU管控的原理，并设计了一个小案例进行演示。详见GaussDB(DWS)的CPU管控实现原理与演示

本篇博文我们根据GaussDB(DWS)的CPU管控原理，探讨其中可能存在的问题，以及如何解决这些问题。

二、cgroup信息

cgroup配置信息保存在cgroup配置文件中，cgroup管控是基于VFS实现的，我们需要将cgroup配置文件中信息映射至VFS中才能实现管控。而为了在内核进程中能够将线程attach到cgroup上，我们需要在内核进程中保存cgroup挂载信息。至此，我们知道需要在以下三个地方保存cgroup信息：

1. cgroup配置文件，通过“gs_cgroup -p”命令可以查看配置文件信息；
2. VFS系统挂载信息，通过“gs_cgroup -P”命令可以查看挂载信息；
3. 内核中cgroup信息，通过“gs_get_control_group_info”视图可以查看内核保存信息。

那如何确认我们本来应该有哪些cgroup呢？我们知道cgroup是绑定在资源池上的，因此我们可以通过查询资源池系统表内信息得到完整的cgroup信息：

select distinct nodegroup,control_group from pg_resource_pool;

下面我们针对以上三个情况进行展开。

注：以下是我们在假设所有过程和逻辑都是不靠谱的情况下，分析cgroup可能存在的问题，以此深入探讨如何进行cgroup的修复。

2.1 cgroup配置文件

因为服务器和进程都可能发生重启，所以我们需要使用文件持久化存储cgroup配置信息。目前我们使用的二进制文件保存cgroup配置信息，示例：$GAUSSHOME/etc/gscgroup_[user_name].cfg。而在逻辑集群模式下，每个逻辑集群会单独保存一份cgroup配置信息，示例：$GAUSSHOME/etc/vc1.gscgroup_[user_name].cfg。后续版本我们计划使用系统表保存cgroup配置信息，不过这是后话了。

GaussDB(DWS)作为分布式系统，通常一套集群内包含多个节点，每个节点上都需要保存完整的cgroup配置，逻辑集群模式下每个节点都需要保存所有逻辑集群的cgroup配置信息。在扩容、容灾、迁移等场景下我们需要将cgroup配置同步至新节点/新集群，而在某些特定版本升级时我们可能需要更新cgroup配置。

这里，我们假设这些过程中都可能出现cgroup配置信息错误、丢失的问题。出现类似问题后，可以参考以下逻辑进行修复：

2.1.1. 使用正确的配置文件进行修复

在旧节点/旧集群cgroup配置文件信息正确，而新节点/集群配置信息错误的情况下。我们可以使用旧节点上配置文件对新节点cgroup配置进行修复：

1. 拷贝旧节点cgroup配置文件至新节点，示例：scp hostname:/$GAUSSHOME/etc/gscgroup_[user_name].cfg $GAUSSHOME/etc；
2. 执行“gs_cgroup --refresh”命令，刷新新节点cgroup信息；
3. 连接数据库，执行内核重新加载：“select * from pgxc_cgroup_reload_conf();”。注：此步正常情况下无需执行，第二步时会自动加载。可以通过将配置文件信息与“gs_get_control_group_info”视图比对，确认信息是否已经重新加载。

2.1.2. 重建cgroup配置文件

在正确的cgroup配置文件已经损坏，无法恢复的情况下，需要重建cgroup配置，重建步骤如下：

1. 参考博客GaussDB(DWS)的CPU管控实现原理与演示中1.2.1章节内容重建cgroup配置文件；
2. 通过pg_resource_pool系统表确认我们需要哪些cgroup；
3. 按照第二步中查询到的cgroup信息，使用“gs_cgroup -c”命令恢复cgroup配置；
4. 执行“gs_cgroup --refresh”命令，刷新新节点cgroup信息；
5. 连接数据库，执行内核重新加载：“select * from pgxc_cgroup_reload_conf();”。

2.2 VFS系统挂载信息

在正常的GaussDB(DWS)节点上，所有配置文件中的cgroup信息都会映射至VFS系统中。而在某些场景下，可能导致cgroup信息丢失。丢失后可以按照以下步骤恢复：

1. 执行“gs_cgroup --refresh”命令，刷新新节点cgroup信息；
2. 连接数据库，执行内核重新加载：“select * from pgxc_cgroup_reload_conf();”。

2.3 内核cgroup信息

在GaussDB(DWS)内核中，使用哈希表保存了cgroup信息，如果意外场景下出现了内核中cgroup信息丢失的情况，可以连接数据库后，调用以下命令恢复：

select * from pgxc_cgroup_reload_conf();

三、常见现网问题

3.1 欧拉系统参数问题

在某些欧拉镜像下，因为systemd配置问题导致cgroup挂载信息频繁丢失。出现类似问题后，首先确认systemd参数是否正确：

systemctl show -- -.slice | grep -i accounting
CPUAccounting=no
BlockIOAccounting=no
MemoryAccounting=no
TasksAccounting=no

正常情况下，CPUAccounting、MemoryAccounting以及CPUSetAccounting子系统配置都是yes，如果是no，可以通过以下命令修改为yes：

systemctl set-property -- -.slice CPUSetAccounting=yes

同时参考2.2章节恢复cgroup挂载信息。

3.2 扩容cgroup配置丢失

某些版本在扩容后，存在cgroup配置文件未同步至新节点的问题，导致后续使用资源池时出现异常：a）用户关联资源池失败；b）新节点上CPU不管控。

出现以上问题后，通过“gs_cgroup -p”命令确认新节点配置文件是否异常，异常情况下参考2.1章节恢复cgroup配置。

3.3 CPU升配/缩配

XX局点CPU升配（48核->96核）后，业务性能无明显提升，通过排查发现前面48个CPU使用率很高，后面48个CPU使用率很低。通过“gs_cgroup -P”命令查看到GaussDB可以使用的CPU核还是0-47，出现类似问题后可以通过以下命令恢复：

gs_cgroup -u -f 0-95 -T Gaussdb

3.4 内核cgroup信息异常

XX局点监控发现，节点CPU使用率出现明显倾斜，而通过作业监控并没有发现明显倾斜。进入CPU使用率异常的节点发现CPU使用率很高，而本来配置的CPU限额隔离配置并没有生效。通过排查配置文件、挂载信息未发现异常。进一步排查发现，内核中cgroup信息出现丢失。通过资源池监控发现，在某些节点上资源池cpu_limit为0。

在这些DN上查询cgroup视图发现，cgroup信息出现丢失。连接DN后，通过以下命令恢复内核cgroup配置：

select * from pgxc_cgroup_reload_conf();

四、总结

从以上内容我们可以看出cgroup问题的定位思路如下：

1. 确认配置文件是否正常；

2. 确认VFS系统挂载信息是否正常；

3. 确认内核中cgroup信息是否正常。

通过以上三步，基本就可以排查出哪里cgroup出现了问题。然后再参考第二章内容修复即可。