【故障】【表空间】绝对表空间使用不规范致使内存异常

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则恢复；