3.1 服务器发生大量系统 CPU 占用问题的原因
问题现象
数据库在运行过程中，因为某些原因出现大量的 CPU sys 占用，进而导致数据库性
能问题。这类问题应该如何去排查？有哪些已知的原因可能导致这类问题的发生？
解决方法
通常大量的系统 CPU 占用是由于资源争抢导致的，如锁资源的争抢、内存的争抢。
用于监控、分析的工具有 perf 、 nmon 等。
GBase 8a MPP Cluster 出现 sys 占用高的几个已知问题原因有：
 操作系统的 NUMA 参数未关闭，在内存紧张情况下可能导致频繁的内存换入
换出导致 sys 高。
 gnode 层的参数设置不合理
_gbase_dc_window_size 设置过小，该参数是可缓存到内存的 DC 数，当需要缓
存的实际数据量超过设置的 DC 数时，就可能导致 sys 占用。
 _gbase_insert_malloc_size_limit 设置过小
在 insert select 场景中，如果存在较大的 varchar 列，如 varchar(2000) ，会导致
每行或每几行申请一次内存，内存频繁申请出现 sys 占用。
3.2 NUMA 参数 zone_reclaim_mode 开启导致数据库性
能低
问题现象
NUMA 参数 zone_reclaim_mode 在设置为 1 时，内核将要求多路 CPU 尽量从距离
较近的系统内存节点（服务器的整体内存在 numa 架构下将被分成若干个节点）分
配内存而不是在整个服务器可访问内存的范围内进行内存分配，因此在较高内存占
用压力下内存申请会触发内存频繁回收整理的机制严重影响了系统整体性能（长期
处于内核态 sys 很高）。
另 外还会 发生部 分 SQL 夯住，从 dmesg 日志 的堆栈 信息中 表现为出 现
kmem_zone_alloc 调用。
处理步骤
NUMA 参数关闭。
 判断是否开启： cat /proc/sys/vm/zone_reclaim_mode
0 ：关闭， 1 ：开启
查看各 cpu 间的 distance ： numactl --hardware
如各 CPU 的 distance > 20 （通讯耗时），则建议开启 NUMA 参数。
 关闭方式：
1 ） vim /etc/sysctl.conf 添加 vm.zone_reclaim_mode=0 并执行 sysctl –p
2 ） sysctl -w vm.zone_reclaim_mode=0
3.3 修改 max_user_processes 参数不生效
问题现象
redhat 操作系统中使用非 root 用户修改 max_user_processes 不生效。
原因分析
安装包中修改参数未生效的原因：
使用 root 用户修改配置文件： /etc/security/limits.conf
增加如下内容：
* soft nproc 10240
* hard nproc 10240
* soft nofile 10240
* hard nofile 10240
其中 nofile 对应 open_files ； nproc 对应 max_user_processes 。
但是在 Linux 6.4 之后，如果只修改了该文件中的 nproc ，那么其他非 root 用户对应
的 max_user_processes 并不会改变，仍然是 1024 ，这个是因为受到了下面这个文件
的影响。
/etc/security/limits.d/90-nproc.conf
查看一下：
# cat /etc/security/limits.d/90-nproc.conf
# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz #432903 for reasoning
* soft nproc 1024
root soft nproc unlimited
处理方法
 修改 /etc/security/limits.d/90-nproc.conf 将
* soft nproc 1024
修改为：
* soft nproc 10240
 修改 /etc/security/limits.conf ，将
* soft nofile 10240
修改为：
gbase soft nofile 10240
3.4 在 redhat7.3 上安装集群安装包中 c3 rpm 包报错
问题现象
# rpm -ivh c3-5.1.2-1.noarch.rpm
Preparing... ###############################
## [100%]
file /usr/bin from install of c3-5.1.2-1.noarch conflicts with file fro
m package filesystem-3.2-21.el7.x86_64
解决方法
这个问题是 c3 安装和 RH7.3 的 filesystem 的文件有冲突，因此报错。
可使用以下命令实现， root 用户或 dbauser 用户。
cd /usr/local
mkdir c3_install && cd c3_install
rpm2cpio xxx/c3.xxxxx.rpm |cpio -idv
cp usr/bin/* /usr/local/bin/ && cp usr/bin/* /usr/bin/
3.5 多 sql 任务并发操作报错 get cluster task id fail
问题现象
现场进行多个 insert...select 的操作，多个任务一起操作的时候， insert 后跟对应的字
段名，执行插入后报错 get cluster task id fail 。
原因分析
gcware 日志中报错：
corosync [IPC ]coroipcs create thread error with errno 11
dmesg 中报错：
[1871111.282609] cgroup: fork rejected by pids controller in /system.slice/gc
ware.service
[2222469.222555] cgroup: fork rejected by pids controller in /system.slice/gc
ware.service
[2414924.406356] cgroup: fork rejected by pids controller in /system.slice/mo
nit.service
根据如上报错， 'fork rejected by pids controller' 说明对进程数是有限制的。
最终原因是因为在 SUSE 12 上增加了 systemd 的资源控制，其中默认参数：
DefaultTasksMax was default value(512).
systemd limited maximum number of tasks that may be created in the unit.
这个值会影响 OS 上的 maxpid 。
解决方法
将参数 DefaultTasksMax 设为无限制后解决该问题：
修改 /etc/systemd/system.conf
设置 DefaultTasksMax 的值为 'infinity' ，重启主机。
说明
 这个问题原因在于 R7 或是 S12 系列，使用了 systemd ，在 R6 或 S11 上没
有，当这个启动后，忽略掉 /etc/security/limits.conf 下的设置。
DefaultTasksMax 参数（默认 512 ）需要放在 /etc/systemd/system.conf
中，我们可以安装集群过程中修改该值，但是如果不重启操作系统的话，
不会生效，这个属于新版操作系统问题，需要在安装集群前设置生效。综
上，需要部署集群前，手动设置。
————————————————