GBase 8a MPP使用时 数据库基础问题之硬件问题

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

中，我们可以安装集群过程中修改该值，但是如果不重启操作系统的话，

不会生效，这个属于新版操作系统问题，需要在安装集群前设置生效。综

上，需要部署集群前，手动设置。