GaussDB(DWS) 多租户资源管理常见定位思路（一）

    当前GaussDB分为线下线上的两种形态，线下的主要由管控面的FusionInsight Manager和GaussDB（MPPDB服务）组成，线上形态由DWS管控面和GaussDB内核组成，以云服务的形态在公有云和混合云（HCS）的形态提供服务。

    关于GaussDB资源管理的一些基本介绍，在上一篇博文中已经基本讲到，可以移步https://bbs.huaweicloud.com/blogs/175191

    本文主要介绍多租户在使用过程中，可能出现的一些问题给定一些基本定位排查的思路：

    主要分为两部分：1）管控面和后台数据库内核系统的交互；2）数据库系统后台和内核的异常情况。

   (PS:针对管控面的部分主要介绍线下场景；线上场景目前没有使用，后续补充)

一、FusionInsight Manager管控面常见定位思路

    1.基本介绍：manager作为gaussdb集群服务的管理，相关的资源配置，要在manager提供的租户资源配置界面进行配置，基本界面示例如下：

    manager的租户配置会涉及到以下几点：

    1. 所有的多租户页面运维操作、监控显示首先会下发rest请求至FIM Web模块，web模块的日志在/var/log/Bigdata/tomcat/web.log

    2. web模块收到页面请求之后将请求转发给aos模块处理，aos模块的日志在/var/log/Bigadata/controller/aos/aos.log

    3. aos模块收到web发来的请求之后，做一些通用处理，然后对调用各组件的插件aos-plugin，各组件在自己的插件中实现自己的多租户机制，插件的日志在    /var/log/Bigdata/controller/aos/plugin.log

    4. 以上1-3的日志均在主oms节点，对于MPPDB组件，aos-plugin会ssh到cm_ctl -Cv查询结果的第一个CN节点执行mpp-userpermission.sh脚本，该脚本的日志在/var/log/Bigdata/mpp/scriptlog/permission/userpermission.log

    5. mpp-userpermission.sh脚本会调用当前节点（主CMS节点）的mpp-sqlExecutor.sh脚本，该脚本的日志在/var/log/Bigdata/mpp/scriptlog/sqlexecutor.log

    6. mpp-sqlExecutor.sh脚本中会执行sql，对资源池进行增删改查以及查询监控信息等

    当管控面出现问题时，可逐步进行排查。

    此外，还有一个常驻进程用来检测cgroup的实时状态：

    日志可以到这个路径查看：/var/log/Bigdata/mpp/healthCheck，该路径中可以查看到cgroup状态检查的日志。如下：

二、内核部分问题常见定位思路

    1.后台命令gs_cgroup -p/P，可以查询后台cgroup配置情况；-p为数据库配置; -P为内存映射，或者说是真实读取cgroup挂载目录进行打印当前的树状信息，示例如下：

gs_cgroup -p

上图为gs_cgroup -p结果，图中可以看到各个控制组锁分配到的CPU数量，Cores数量即可以使用的CPU核数目。

解说一下上图：

 首先前提是每个group都有一个GID（group id），例如第一行，GID=0的root控制组节点。其次，每一行都有当前控制组的对应信息，比如Percent，代表CPU配额百分比，即CPU时间百分比，Cores代表该控制组可以使用的CPU的范围。

1）Top Group即为最上层的各个资源分配顶点，包括了：Root，Gaussdb：omm，Backend，Class，其中，Root和Gaussdb：omm是平级的，而Backend和Class相当于Gaussdb：omm的子节点。以配比40和60来分配Gaussdb：omm下的CPU资源。

2）Backend下又会挂载这DefaultBackend和Vacuum两个节点，这两个节点用于后台常驻线程和Vacuum线程的资源分配。

3）Class Group information和Workload Group，对应了用户所使用的正常工作线程的位置，如果用户制定了控制组，比如图中的class_a，GID=22，可以看到GID=88的控制组wg2:2，对应的ClasGID=22，就表明了wg2:2控制组是class_a控制组的子控制组。

gs_cgroup -P

这个命令会打印一个树形结构，会比较清晰一点，执行之后示例如下：

从图中可以看到每个根节点都对应一个控制组，可以详细看到哪个控制组是在哪个节点下。下方对应的数字，即是OS级别的pid，挂载到对应的控制组下，就代表着这些线程可以使用节点第一行的所描述的CPU资源信息。

三、数据库内部相关的控制组信息查询：

数据库内部也提供了几个表，用于记录各个用户所对应的资源池，控制组，每个用户可以使用什么资源都可以在后台查询的到。

1）pg_user表，该表记录用户信息，并且其中respool字段可以看到该用户当前处于哪个资源池。

2）pg_resource_pool表，可以查看每个资源池对应的信息，也有该资源池对应的控制组，资源池上的并发量(active_statements)，简单作业并行数目（max_dop）等信息。

3）gs_all_control_group_info表，可以查到控制组相关的一些信息，包括该控制组属于哪一个Class控制组，分配了多少cpu的配额时间(shares)和cpucore数量(cpucores)

4）pg_session_wlmstat视图，可以查看到每条语句，语句是简单作业还是复杂作业(attribute)，复杂作业会受对应资源池的资源管控，并且可以看到该语句是在那个控制组、资源池下执行（分别对应control_group字段和resource_pool字段）。