【维护案例】绝对表空间使用不规范致使内存异常

1.  问题描述

版本：GaussDB A-8.0.0.1

1月18日下午3时，客户反馈执行业务脚本报错：-bash: fork: Cannot allocate memory，执行基本的OS命令均不能成功。

2.  问题根因分析：

1.       查看OS日志，发现一Gauss进程占用内存达到130G+，系统内存不足，将其kill；

2.       查看Gauss进程启动时间，找到一节点启动时间在报错时间段

3.       使用top命令查看此节点内存占用情况，此时已达到130G+；

4.       登录此节点查看每个session所占用的内存，找到一个异常session内存占用达到140G+，且还在不停的快速增长；

5.       根据其pid通过数据库视图查到异常的sql语句为gs_rewind发起，其与相应备节点的build相关；

6.       该语句会扫描实例下的所有数据，由于使用绝对表空间并将位置定义到了data1，导致扫描产生死循环；

7.       因此，此sql不断占用内存，最后将系统内存耗尽，产生报错。

3. 根因分析：

备机修复的时候会去主实例同步数据，主实例扫描节点下数据，由于使用绝对表空间且其路径定为/srv/BigData/mppdb/data1,主实例会去目录扫描，造成死循环，因此消耗大量内存导致节点被kill。

4. 规避措施  ：

方案中所有图片均为家里复现收集，实际以现场环境为主！

1.       登录数据库后使用\db查询表空间，可以看到wd使用了绝对路径，此路径造成备机build的死循环；

2.       找到所有CN所在路径：cm_ctl query –Cvd| grep coo，截图保留；

3.       停集群，cm_ctl stop -mi；

4.       进入物理机1上的/srv/BigData/mppdb/data1目录；

5.       mkdir创建一个文件夹，并将所有PG目录拷贝到新建的目录中；

6.       其他物理机重复此操作；

7.       回到物理机1上，进入/srv/BigData/mppdb/data1目录后，进入到master下的pg_tblspc目录，将软连接更新为刚创建的目录的绝对路径；

8.       进入到/srv/BigData/mppdb/data1下的slave目录，再进入至pg_tblspc目录，同样更新软连接；

9.       进入到/srv/BigData/mppdb/data2下的master目录，重复7~8步，直至物理机上所有的master、slave均更新了表空间软连接；

10.   再到物理机2上重复7~9，直至所有机器完成；

11.   登录到相应机器上的CN目录（步骤2），在pg_tblspc下同样更新软连接；（每台机器都要做）

12.   启动集群：cm_ctl start；

13.   登录数据库查看表空间绝对路径是否发生变化；

14.   查看此时集群状态以及内存情况，无占用内存过高的session且集群状态变为normal则恢复；