本文在Redhat 7.6环境使用Greenplum 6.9.0（部署在一台物理机上，2个segment）测试通过。
一、cgroups配置
安装cgroup工具
- snippet.bash
sudo yum install libcgroup-tools
创建配置文件
- snippet.json
[gpadmin@bogon ~]$ sudo vi /etc/cgconfig.d/gpdb.conf group gpdb { perm { task { uid = gpadmin; gid = gpadmin; } admin { uid = gpadmin; gid = gpadmin; } } cpu { } cpuacct { } cpuset { } memory { } }
注：/etc/cgconfig.d/这个目录，在安装libcgroup-tools之后才会生成。
解析conf文件和并挂载层级
- snippet.bash
[gpadmin@bogon ~]$ sudo cgconfigparser -l /etc/cgconfig.d/gpdb.conf
识别cgroups命令挂载点（mount point）
看命令输出结果第一行。
- snippet.bash
[gpadmin@bogon ~]$ grep cgroup /proc/mounts tmpfs /sys/fs/cgroup tmpfs ro,seclabel,nosuid,nodev,noexec,mode=755 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,seclabel,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0 cgroup /sys/fs/cgroup/pids cgroup rw,seclabel,nosuid,nodev,noexec,relatime,pids 0 0 ……
或者，
- snippet.bash
[root@bogon ~]# grep cgroup /proc/mounts | head -n 1 | awk '{print $2}' /sys/fs/cgroup
验证cgroups配置是否正确
- snippet.bash
[root@bogon cgroup]# grep cgroup /proc/mounts|head -n 1|awk '{print $2}'|xargs -i ls -l {}/{cpu,cpuacct,cpuset,memory}/|grep -w gpdb|awk '{print $3":"$4}'|uniq gpadmin:gpadmin
或者，
- snippet.bash
ls -l <cgroup_mount_point>/cpu,cpuacct/gpdb ls -l <cgroup_mount_point>/cpuacct/gpdb ls -l <cgroup_mount_point>/cpuset/gpdb ls -l <cgroup_mount_point>/memory/gpdb
启动cgconfig服务
Redhat/CentOS 7.x and SuSE11+系统：
- snippet.bash
# 重启系统生效： sudo systemctl enable cgconfig.service # 立即生效： sudo systemctl start cgconfig.service # 查询状态： sudo systemctl status cgconfig.service
Redhat/CentOS 6.x系统：
- snippet.bash
sudo chkconfig cgconfig on
二、Greenplum
设置资源管理器为"group"
安装GPDB时，默认情况下会启用资源队列。要使用资源组而不是资源队列，必须设置gp_resource_manager服务器配置参数为值"group"，重启GPDB才会生效。
- snippet.bash
[gpadmin@bogon ~]$ export PGPORT=7456 [gpadmin@bogon ~]$ gpconfig -s gp_resource_manager Values on all segments are consistent GUC : gp_resource_manager Master value: queue Segment value: queue [gpadmin@bogon ~]$ gpconfig -c gp_resource_manager -v "group" 20200722:20:24:39:053663 gpconfig:bogon:gpadmin-[INFO]:-completed successfully with parameters '-c gp_resource_manager -v group'
重启GP服务
- snippet.bash
[gpadmin@bogon ~]$ gpstop -r -a [gpadmin@bogon ~]$ gpconfig -s gp_resource_manager Values on all segments are consistent GUC : gp_resource_manager Master value: group Segment value: group
启用后，角色提交的任何事务都将定向到分配给该角色的资源组，并受该资源组的并发、内存和CPU限制的约束。同样，外部组件的CPU和内存使用量由为分配给组件的资源组配置的CPU和内存限制控制。
GPDB为角色创建了名为admin_group和default_group的两个默认资源组。启用资源组时，将为未明确分配资源组的任何角色分配角色功能的默认组。SUPERUSER角色分配了admin_group，非管理员角色分配了名为default_group的组。
三、验证CPU按比例配额
完成上述配置后，接下来我们做一个小实验，验证资源组控制不同角色CPU使用比例。
创建资源组
创建资源组rgroup1，调整缺省资源的CPU配额比例值。default_group、admin_group和rgroup1资源组的CPU配比为：10:10:5 = 2:2:1。查看设置结果：
- snippet.sql
tpch1s=# CREATE RESOURCE GROUP rgroup1 WITH (CPU_RATE_LIMIT=5, MEMORY_LIMIT=25, MEMORY_SPILL_RATIO=20); tpch1s=# ALTER RESOURCE GROUP admin_group SET CPU_RATE_LIMIT 10; tpch1s=# ALTER RESOURCE GROUP default_group SET CPU_RATE_LIMIT 10; tpch1s=# SELECT * FROM gp_toolkit.gp_resgroup_config; groupid | groupname | concurrency | cpu_rate_limit | memory_limit | memory_shared_quota | memory_spill_ratio | memory_auditor | cpuset ---------+---------------+-------------+----------------+--------------+---------------------+--------------------+----------------+-------- 6437 | default_group | 20 | 10 | 0 | 80 | 0 | vmtracker | -1 6438 | admin_group | 10 | 10 | 10 | 80 | 0 | vmtracker | -1 16385 | rgroup1 | 10 | 5 | 25 | 80 | 20 | vmtracker | -1 (3 ROWS)
创建角色
使用超级用户创建一个新角色yz，并指派资源组rgroup1：
- snippet.sql
tpch1s=# CREATE ROLE yz WITH SUPERUSER CREATEDB CREATEROLE LOGIN REPLICATION INHERIT PASSWORD '111' RESOURCE GROUP rgroup1; tpch1s=# \du List OF roles ROLE name | Attributes | Member OF -----------+-----------------------------------------------------------------------+----- gpadmin | Superuser, CREATE ROLE, CREATE DB, Ext gpfdist TABLE, ……, Replication | {} yz | Superuser, CREATE ROLE, CREATE DB, Replication | {} -- 查询角色与资源组之间关系： tpch1s=# SELECT rolname, rsgname FROM pg_roles, pg_resgroup WHERE pg_roles.rolresgroup=pg_resgroup.oid; rolname | rsgname ---------+------------- gpadmin | admin_group yz | rgroup1 (2 ROWS)
允许新用户连接数据库
修改master节点pg_hba.conf配置文件：
- snippet.bash
vim /opt/gp/gpmaster/gpseg-1/pg_hba.conf # 修改 host all gpadmin,yz 127.0.0.1/28 trust host all gpadmin,yz 192.168.0.219/32 trust host all gpadmin,yz ::1/128 trust
如果新用户无法登录，请参考：Greenplum新建用户无法登录问题。
验证
从两个psql客户端分别连接GP数据库，同时执行一条耗CPU的长查询（例如，热数据 TPC-H q1）：
- snippet.bash
[gpadmin@bogon ~]$ psql -d tpch1s tpch1s=# \i q1.sql [gpadmin@bogon ~]$ psql -h 127.0.0.1 -d tpch1s -U yz tpch1s=# \i q1.sql
监视进程postgres进程使用率，gpadmin用户和yz用户的CPU使用率近似2:1，符合预期：
四、迁移查询至其它资源组
GPDB 从v6.8开始，运行管理员将正在执行的查询从一个资源组迁移到另一个资源组。例如，用户yz指派了资源组rgroup1，该用户执行的某个查询进程号为pid，管理员可以根据当前资源组使用情况，临时将正在执行的资源组迁到另一个资源组rgroup2上继续运行（无需中断查询），以达到临时调配资源目的。
函数
查询迁移资源组功能函数为：
- snippet.sql
gp_toolkit.pg_resgroup_move_query( pid int4, group_name text );
注：v6.8 ~ v6.10，上述函数在gp_toolkit schema中，而在当前master分支，已经移出gp_toolkit了。
示例
在第1个psql客户端，使用admin_group资源组执行一个长查询：
- snippet.sql
[gpadmin@bogon ~]$ psql -d tpch1s # 第1个psql客户端 tpch1s=# \i ~/1.sql
在第2个psql客户端，先查询上述查询的pid、资源组等信息，然后将上述查询迁移到另一个资源组，并确认是否迁移成功。
- snippet.sql
[gpadmin@bogon ~]$ psql -d tpch1s # 第2个psql客户端 tpch1s=# SELECT pid,sess_id,query,rsgid,rsgname FROM pg_stat_activity; -- 迁移前状态 pid | sess_id | query | rsgid | rsgname ---------+---------+------------------------------------------------------------------------------+-------+------------- 2933567 | 6 | SELECT +| 6438 | admin_group | | l_returnflag, +| | | | l_linestatus, +| | | | SUM(l_quantity) AS sum_qty, +| | | | SUM(l_extendedprice) AS sum_base_price, +| | …… -- 上述查询pid为2933567，资源组是admin_group（oid为6438）。 tpch1s=# SELECT gp_toolkit.pg_resgroup_move_query(2933567, 'default_group') FROM pg_stat_activity; -- 迁移到default_group资源组 -- 如果是master分支，迁移命令为： -- SELECT pg_resgroup_move_query(2933567, 'default_group') FROM pg_stat_activity; tpch1s=# SELECT pid,sess_id,query,rsgid,rsgname FROM pg_stat_activity; -- 迁移后状态 pid | sess_id | query | rsgid | rsgname ---------+---------+------------------------------------------------------------------------------+-------+--------------- 2933567 | 6 | SELECT +| 6437 | default_group | | l_returnflag, +| | | | l_linestatus, +| | | | SUM(l_quantity) AS sum_qty, +| | | | SUM(l_extendedprice) AS sum_base_price, +| | …… -- 可以看到，pid为2933567的查询以及迁移到default_group组（oid为6437）
另外，我们也可以从cgroups状态判断是否迁移成功。
- snippet.sql
tpch1s=# SELECT * FROM gp_toolkit.gp_resgroup_config; groupid | groupname | concurrency | cpu_rate_limit | memory_limit | memory_shared_quota | memory_spill_ratio | memory_auditor | cpuset ---------+---------------+-------------+----------------+--------------+---------------------+--------------------+----------------+-------- 6437 | default_group | 20 | 30 | 0 | 80 | 0 | vmtracker | -1 6438 | admin_group | 10 | 10 | 10 | 80 | 0 | vmtracker | -1
从GPDB资源组配置可知，目标资源组default_group的CPU资源控制使用的是"cpu_rate_limit"，我们可以通过查看/sys/fs/cgroup/cpu/gpdb/6437/tasks是否有以上进程pid（已经相关计算与管理进程的pid）来确认迁移是否成功：
- snippet.bash
[gpadmin@bogon ~]$ cat /sys/fs/cgroup/cpu/gpdb/6437/tasks 2933567 2933568 2935432 ……