cgroup 丢失，导致 OCP 租户 CPU 监控数据异常为 0 问题

问题现象

1. 某生产环境 OceanBase 数据库 V4.2.1 版本，OceanBase 数据库和 OCP 未做变更情况下，OCP 租户 CPU 监控数据突然跌 0，如下图所示。

   

2. 当在测试环境 OCP 升级时，也遇到租户 CPU 监控数据突然跌 0 情况，如下图所示。

   

操作系统版本： 麒麟 v10sp3_x86_64-build23/20230324。

对应的 systemd 版本： systemd 243 (v243-55.p01.se.01.ky10)。

OceanBase 数据库版本： OceanBase 数据库 V4.2.1 版本。

关键信息

cgroup 丢失。

问题原因

OceanBase 数据库 V4.x 在高版本 Linux 下（如麒麟 v10-sp3）重装/删除软件后，存在 systemd reload 导致 cgroup 失效丢失，从而引起 OCP 监控数据丢失。

问题根因分析

排查 /var/log/messages 日志，发现 ocp_agent 重装过程会触发 systemd reload 操作（如下图示例，systemd[1]: Reloading. 行）。

类似的，尝试手动执行 systemctl daemon-reload 命令，确认同样会导致 observer pid 位置变化。

那么问题的原因就是因为在重装 ocp_agent 时会写一个 ocp_agent.service 配置，触发了 systemd 自动 daemon-reload 操作导致该问题，老版本 systemd 不会自动 reloading，可能是部分 OS 高版本 systemd 的新功能（或 BUG）。

为什么 daemon-reload 操作会导致 pid 位置变化

上图 8： 处可以看到 OceanBase 进程 cpu cgroup 原本是在 /oceanbase/other 这个域的。

由于 OceanBase 在处理 cgroup 时，并没有为 OceanBase 在 systemd cgroup 目录下创建策略组，那么就会导致 systemd 在 reload 时会按它默认的策略（按 user.slice 管理），把进程挪到 user.slice 目录下。

同理，根据此思路排查生产环境，在没有 OCP 升级情况下，也突然跌 0 问题。

排查生产环境操作系统 message 日志，该时间点，也有 systemd reload。

原因是该时间点生产环境所有主机安装了可观测平台的 agent 采集探针 deepflow-agent-1.0-4903.el7.x86_64，该可观测 deepflow-agent 也是一个 service 服务，重装也导致了systemd reload。

到此，cgroup 丢失，导致 OCP 租户 CPU 监控数据异常跌 0，根本原因已确定。

问题的风险及影响

• cgroup 丢失导致 OCP 监控数据丢失。

• 部分高版本 OS 内核里都会有，如下。

  • 在公有云 8u 环境也能复现。

  • 在高版本 redhat 8.9 上也碰到了类似的问题。

  • 麒麟 v10sp3_x86_64-build23/20230324，对应的 systemd 版本：systemd 243 (v243-55.p01.se.01.ky10)。

影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

适用版本

OceanBase 数据库 V4.x 所有版本。

解决方法

临时方案：

• 重启 OBServer 恢复 cgroup。

• 避免 systemd reload 的时候变动（下次重启 OBServer 以后需要重新处理一遍）。

  echo $(pidof observer) > /sys/fs/cgroup/systemd/cgroup.procs
  

规避方式

目前 OCP V4.3.4 版本已优化 OceanBase 数据库 V4.x 在高版本 Linux 下（如麒麟 v10-sp3）重装/删除软件后 cgroup 失效问题，但仅对新建集群有效，对于 OCP 目前已接管和创建的集群无效。 彻底解决需要升级 OceanBase 数据库版本至 V4.4.1 Hotfix1（oceanbase-4.4.1.0-100010052025101619）。