句柄回收空间不释放

网友投稿 687 2022-05-28

关键字:

句柄不回收;空间不释放;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

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

任务调度

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:《TypeScript图形渲染实战:2D架构设计与实现》 —3.2.6 CanvasInputEvent及其子类
下一篇:2021年大数据Spark(十八):Spark Core的RDD Checkpoint
相关文章