句柄不回收，空间不释放

         句柄不回收；空间不释放；deleted；磁盘满；磁盘使用率高；

现象：

         磁盘使用率高，df -h和du -sh查看数据目录，发现大小不同，差别很大。lsof查看发现有大量的文件处于deleted状态：

这类文件分三种，按照下面命令可以统计这类不回收文件的数量

1. base 目录下数据文件：

lsof|grep deleted |grep base| wc -l

2. pg_xlog目录下的xlog文件；

lsof|grep deleted |grep pg_xlog| wc -l

3. cm和om目录下的各种目录文件，这类文件句柄查出来有很多重复的，一般情况不用处理；

通过lsof|grep deleted |grep '.log'| wc -l

规避措施：

1. base目录下数据文件和pg_xlog下xlog文件可以采用以下方法之一进行处理：

方法一：kill dn实例。具体操作步骤如下：

• gsql 连接CN, 执行checkpoint；
• 在空间不回收的实例上杀掉dn进程; 这里27620是上图中dn的进程号，实际操作请替换给对应的进程号：

         kill -9 27620

影响：kill DN实例会导致当前业务执行报错，请确认后操作;

方法二：在线清理句柄。具体操作如下：

• 连接CN执行checkpoint；
• 连接CN清理每个库的空闲连接：

        clean connection to all for database xxxx;

这里xxxx是数据库名称，通过 \l 命令可以查看当前所有数据库。对每个库都做同样的清理。

该动作知会清理idle连接，不影响业务。

• 如果前面两步执行完，空间依旧不释放，说明可能存在长连接，连接空间不释放的实例，找出这些连接，全部杀掉即可。查询语句如下：

select now()-query_start as ctime, * from pg_stat_activity where state='idle' order by ctime desc;

杀语句方法：

select pg_terminate_backend(pid) from pg_stat_activity where state='idle' order by ctime desc;

2. cm和om日志，这部分使用空间不大，一般只有几十MB，可以不用处理。但是部分异常情况下，日志没有分割，导致占用空间比较大：

规避措施分两步：

• 查看om日志持续上涨的原因，这里27709是上图中的进程号，3是文件句柄：

tailf /proc/27709/fd/3

根据报信息找研发处理对应报错；

• 清理存量数据

cat /dev/null > /proc/27709/fd/3

注释：该方法不会释放文件句柄，只是释放空间，并保证空间不会上涨。