磁盘使用率相关问题定位指南

一、定位思路

1.1 核心思想

确定是哪个目录占用空间异常，再具体处理

1.2定位三板斧

1.       通过横向与纵向对比，确定占用空间异常的实例与最小级别目录。（横向对比：单实例或部分实例磁盘使用率异常时，对比不同实例上各目录大小差异；纵向对比：所有实例磁盘使用率异常增高时，与之前的磁盘使用情况进行对比）

2.       确认目录后按照对应场景处理

3.       磁盘使用率达到90%后，处理时需注意集群的只读状态；磁盘使用率达到100%后，直接联系华为工程师

二、定位分析

2.1常用命令

查看磁盘使用率

df -h

查看某个目录占用空间大小

du -sh 目录

查看当前目录下各文件/目录占用空间大小

du -sh *

查看集群状态（包含实例目录）

cm_ctl query -Cvd

查看对应dn的端口号

cat dn目录/postgresql.conf |grep port

例：cat /srv/BigData/mppdb/data1/master1/postgresql.conf | grep port

2.2场景划分

目录结构概览（此处只列举常见目录，下层目录只以master为例展开）

2.2.1 archive目录占用空间较大

现象

单个或多个实例archive目录占用空间较大

根因

打开了日志归档参数archive_mode，导致archive目录下不断归档xlog，占用空间越来越大

应急

1）  关闭归档参数

gs_guc reload -Z coordinator -Z datanode -N all -I all -c "archive_mode=off"

2）  手动清理archive目录下的归档日志（归档日志并不影响集群运行，一般不建议打开。现网问题删除操作需与客户确认）

archive目录下文件数量过多时，可能无法使用rm -f *命令进行删除，可参看以下命令分批删除

find -name "*" | xargs -n 10 rm -f

2.2.2 pg_xlog目录占用空间较大且未打开归档

现象

pg_xlog占用空间大，pg_xlog目录下文件数量多，archive目录占用空间不大

分析

1）  遇到此场景时，优先查看集群状态，确认此dn的对端（例：dn6001的对端是dn6002）是否状态异常，若当前dn为从备，则查看同一dn环的主备是否有一个发生故障。当主备有一个dn状态异常时，另一副本数据和xlog会存放在从备，在备机恢复之前不会回收。若遇到此场景，则应优先考虑如何将集群恢复为normal。

2）  若集群状态正常，主dn的xlog过多，可能是因为主备xlog同步较慢导致，可在备机所在节点执行”gs_ctl querybuild -D 备机目录”查看同步进度

3）  若主备日志同步进度为100%，大量xlog为最近突然产生，则排查业务上是否有带索引导入的场景。导入的目标表如果有索引，有可能产生大量xlog

根因

1）  主备dn有一个发生故障导致xlog在当前主机和从备积压

2）  主备日志同步较慢导致主dn日志堆积

3）  带索引导入产生大量xlog

应急

1）  若满足根因1，则优先恢复集群状态，恢复normal后会自动进行xlog同步，同步结束后自动回收

2）  若满足根因2，则查看IO状况，结合日志分析

3）  若满足根因3，则排查业务侧是否有对应情况，中断该业务，删除目标表的索引，再导入，导入结束后再重新创建索引

4）  若无法快速恢复集群状态，或无法快速定位，此场景可直接联系华为工程师处理

2.2.3 pgsql_tmp目录占用空间大

现象

单个或多个实例的pgsql_tmp目录占用空间大

分析

psql_tmp目录存放的是临时下盘文件，这个目录大说明产生了大量的算子下盘，需找到具体语句，杀掉该语句后空间自动恢复

pgsql_tmp目录下临时文件的命名方式类似pgsql_tmp140359455721216.9，其中红色部分表示产生该临时文件的线程号，最后的9表示这个文件是该线程产生的第九个文件

根因

临时文件下盘

应急

1）  通过查看pgsql_tmp目录下的文件名，确定产生下盘文件的线程号

2）  根据该线程号，连到对应实例（-d 使用postgres即可，因为pg_stat_activity可以查到所有库的；-p 使用该实例的端口号，查看端口号的方法参考2.1常用命令），执行

”select * from pg_stat_activity where pid = pid”

即可查到产生下盘文件的语句

3）  在该实例执行

”select * from pg_terminate_backend(pid)”

 即可杀掉该语句

4）  对该业务语句进行调优，优化后再上线

5）  若情况比较紧急，可直接kill dn进行应急，但是如果不定位到具体语句，业务再次拉起后仍会复现

2.2.4 base目录下的database目录占用空间异常增高

现象

单个或多个实例base目录下的库目录（除pgsql_tmp以外的目录）占用空间高

分析

遇到此场景时，应优先确定是部分dn的database目录占用空间大，还是所有dn的database目录占用空间都高。如果是部分dn，则通过对比正常dn和异常dn目录下的文件找到占空间大的对象；如果是所有dn的database目录都异常增高，则选择一个dn实例排查大表或最近更新的文件。

database目录下，文件的命名方式，行存表或行存表分区为12345.1，其中红色部分为relfilenode，最后的数字表示这是该relation的第几个文件；列存表为12345_C10.1，其中红色部分表示relfilenode，C10表示这是第几列，最后的数字表示这是该relation第10列的第几个文件；每个文件大小达到1G后开启下一个文件

详细步骤如下

1.       部分dn的库目录占用空间大

1）  database的oid在不同dn上有可能不同

分别连接（-d postgres -p 对应dn端口）异常dn和正常dn，执行”select oid,* from pg_database” 并结合base目录下各database目录的大小，进行比对，确定占用空间高的database

2）  在正常dn和异常dn分别进入该目录，执行ll *.100

对比两边大于100G的relation数量，例如正常dn是3个，异常dn是5个，有明显差异，则对异常dn上5个大于100G的relation均进行排查（因为同一个relation的relfilenode在不同dn可能不同，因此不能直接确定排除哪3个）；如果在正常dn和异常dn上的结果一致，则缩小范围，例如ll *.50，ll *.10，ll *.5甚至ll *.1进行对比，找到差别后依次排查，数量较多时可在文本编辑器中使用列编辑功能批量编辑sql语句。

连接到异常dn对应的database，执行

”select * from pg_class where relfilenode = relfilenode”

如果可以查到结果，则relname就是对应的relation，可能为表或者索引；

如果在pg_class中查不到对应的relation，则执行

”select * from pg_class where oid = (select parentid from pg_partition where relfilenode = relfilenode)”

如果可以查到结果，则说明该relation是分区表的一个分区，我们通过上面的语句查到了对应的主表；

当查到对应的表或索引后，可以通过执行

“select * from pg_namespace where oid = relnamespace”

获得该对象的schema，其中relnamespace可以在pg_class的结果中获得；如果操作人员知道对应表的schema，则可以跳过此步骤

如果在pg_class和pg_partition中都查不到记录，则需进一步确认该relation是否为系统表，此时建议联系华为工程师处理。

3）  通过上一步，我们找到了怀疑对象，接下来要进行确认

对每一个怀疑对象（表或索引），连接到正常dn和异常dn的对应database库，分别执行

”\dt+ schema.relation”

对比该对象在两个dn上占用空间大小，若大小确实相差较大，则说明该对象是我们要找的目标

4）  确定所有目标对象后，依次进行处理

若对象为索引，则排查索引对应的表是否也存在倾斜；连接到正常dn和异常dn的对应database，执行

“select count(*) from schema.relation”

若表有明显倾斜，则对表进行整改；若表没有倾斜，则执行reindex重建索引

“reindex table schema.relation”

若对象为表，则直接在正常dn和异常dn的对应database，执行

“select count(*) from schema.relation”

若表有明显倾斜，则对表进行整改；若表没有倾斜，则对该表做vacuum full

“vacuum full table”

5）  若清理大表之后，空间仍未下降，则查看文件fd是否仍被占用

“lsof -n $data目录 |grep deleted”

若出现此情况，空间最终会被释放，但是可能比较慢，可以kill dn进程快速恢复

2.       所有dn的database目录都高，则选择一个dn进行分析

1）    连接到对应dn，执行

“select oid,* from pg_database”

结合base目录下各database目录的大小，确定占用空间高的database

2）    进入该database目录，执行ll *.100，找出占用空间大的relation，若结果为空，则依次执行ll *.50，ll *.30，ll *.10，ll *.5，ll *.1等，查找占用空间大的对象；若无明显占用空间大的对象，或大小接近的对象数量非常多，则根据磁盘空间上涨的时间，查看最后更新时间与上涨时间接近的文件，确定relfilenode

3）    连接到该dn对应的database，执行

”select * from pg_class where relfilenode = relfilenode”

如果可以查到结果，则relname就是对应的relation，可能为表或者索引；

如果在pg_class中查不到对应的relation，则执行

”select * from pg_class where oid = (select parentid from pg_partition where relfilenode = relfilenode)”

如果可以查到结果，则说明该relation是分区表的一个分区，我们通过上面的语句查到了对应的主表；

当查到对应的表或索引后，可以通过执行

“select * from pg_namespace where oid = relnamespace”

获得该对象的schema，其中relnamespace可以在pg_class的结果中获得；如果操作人员知道对应表的schema，则可以跳过此步骤

如果在pg_class和pg_partition中都查不到记录，则需进一步确认该relation是否为系统表，此时建议联系华为工程师处理.

4）    对查出来的表，在该dn上执行

“\dt+ schema.relation”

查看目标对象在单dn的大小，对占用空间过大的表进行清理（需客户同意）（如果是用delete的方式清理，则清理之后需再做vacuum full）

5）    若清理大表之后，空间仍未下降，则查看文件fd是否仍被占用

“lsof -n $data目录 |grep deleted”

若出现此情况，空间最终会被释放，但是可能比较慢，可以kill dn进程快速恢复

2.2.5 其他场景一：core文件生成过多导致磁盘空间占满

现象

实例频繁core导致core文件过多将磁盘占满

分析

查看core文件的路径

”cat /proc/sys/kernel/core_pattern”

core文件占用空间过大，则重新配置core名称，使core文件每次进行覆盖，每个实例最多保存一个core

应急

1）   echo "core" >/proc/sys/kernel/core_pattern

2）   kill om_monitor

3）   kill cm_agent

保留一两个core文件，删除其他core文件，联系华为工程师分析

2.2.6 其他场景二：单个日志文件过大导致/var/log目录磁盘空间占满

现象

单个日志文件过大（om_monitor日志或system_call日志）导致/var/log目录占满

应急

1）  将大日志文件cp到其他目录；如果文件过大或情况紧急，则跳过此步骤

2）  清空该日志文件内容

echo ‘cleanup’ > 日志文件

3）  联系华为工程师进一步分析

2.2.7 其他场景三：xfs文件系统预分配导致磁盘使用率高

现象

base目录下某个database目录占用空间大，但是找不到大文件

分析

遇到此场景时，统计该database目录下文件总大小，与”du -sh *”的结果相比较，如果相差较多，说明是因为新建了大量的列存宽表，产生大量文件，每个文件在xfs上都会预占16M空间，导致磁盘空间上涨

应急

1）    以root用户登录空间占用高的服务器，执行以下语句释放预占空间

sync

/sbin/sysctl -w vm.drop_caches=3

2）    部署drop cache脚本

2.3 磁盘空间达到90%

单个或多个RAID组的磁盘使用率超过90%后，集群会变为只读状态，无法进行写操作。根据第三章的方法进行定位，如果处理时涉及重分布、vacuum full、reindex等操作，需要先解除集群的只读状态。这些手段使用时都会使磁盘空间先升后降，因此必须确保剩余空间足够进行这些操作。

解除集群只读：

1.       在所有cn节点配置白名单，防止取消只读状态后有业务接入将磁盘插入至100%

cp /srv/BigData/mppdb/data1/coordinator/pg_hba.conf /home/omm/pg_hba.conf_`date +'%Y-%m-%d_%H%M%S'`

sed -i 's/.*sha256.*$/#&/g' /srv/BigData/mppdb/data1/coordinator/pg_hba.conf

2.       连接数据库cn，确保当前没有正在执行的业务语句

3.       在主备cm_server节点的/opt/huawei/Bigdata/mppdb/cm/cm_server/cm_server.conf中修改

enable_transaction_read_only=off（关闭集群只读监控）

依次kill -9 cm_server备机和主机进程（kill前后分别观察进程号，进程号变化表示成功）

4.       在后台取消只读状态

gs_guc reload -Z coordinator -N all -I all -c "default_transaction_read_only = false"

5.       把所有cn都kill一遍，防止有遗漏的正在执行的语句

执行完相关操作，确认空间已恢复后，需恢复集群白名单配置和CM的只读检测

此处需注意，一定要恢复白名单和CM的只读检测，否则下次磁盘使用率超过90%时将无法将集群置为只读状态，带来严重后果

1.       在主备cm_server节点的/opt/huawei/Bigdata/mppdb/cm/cm_server/cm_server.conf中修改

enable_transaction_read_only=on

依次kill -9 cm_server备机和主机

2.       在所有cn节点恢复集群白名单配置

sed -i '/^#.*sha256.*$/s/^#//' /srv/BigData/mppdb/data1/coordinator/pg_hba.conf

2.4         磁盘空间达到100%

啥也别想了，赶紧找研发！