1 说明
最近在一线交付作中遇到了四五次pg系数据库antdb文件系统使用率突增的问题：
数据文件目录两三个小时内涨了几个T的数据。主要分为两种情况：一是短期有大表创建或大量数据写入；二是短期有大量磁盘密集型临时操作，如排序、分组等大型查询溢出，笛卡尔积连接等。
虽然磁盘空间问题虽然看起比较平常，但因为postgresql数据库的存储机制是标准文件系统，当磁盘使用率激增至满时，会直接影响数据库的正常运行。若处理不及时，甚至可能导致数据库宕机，造成严重事故，因此必须引起高度重视。
2 排查过程
以下分享在实际工作中，针对pg分布式环境下文件系统使用率突增问题的排查分析过程，排查思路同样适用于集中式部署环境。
2.1 检查当前活动会话情况
确认当前活跃会话数量是否显著高于日常水平，识别异常会话。
检查有没有异常会话，如长时间运行的事务、创建临时表的操作等。
如果是分布式环境，需要去每一个cn节点分别查看活跃会话情况。
2.2 检查异常大表
定位是否存在 TB 级别的异常大表占用空间。
我处理过的几起问题中，有一半以上都是因为有异常大表占满磁盘空间：
在相关环境中，最大的业务表也就500G，像上面这张2.4T的表明显不正常了，集群dn节点一般剩余的可用磁盘空间也就3-5T，两张大表就能打满磁盘了。
此类数 TB 大表的产生，多因开发人员执行了产生笛卡尔积结果的CTAS和插入语句，或者大量排序和分组语句所致，需加强SQL编写规范与审核。此问题已多次发生他们还是不长记性！
2.3 检查临时文件
若未发现异常大表，则问题很可能集中在临时文件上。
这个步骤主要是进入数据路径下的base/pgsql_tmp目录，查看是否有很大的临时文件，或者某个进程有大量临时文件的，找到该pid，并到相关节点处理。
2.3.1 临时文件少
如果目录下临时文件不多，可以通过翻页，或将临时文件大小排序找出最大的临时文件：
du -sh * | sort -h | cut -d. -f1
2.3.2 临时文件多
如果临时文件很多：
若临时文件数量巨大（例如上图所示达 50万个），而活跃会话仅数十上百个，表明少量异常会话生成了绝大多数临时文件。
使用以下命令找出生成临时文件最多的进程：
ls -l | awk '{print $9}' | cut -d. -f1 | sort | uniq -c
3 处理
3.1 大表处理
此类表通常为无效数据或错误操作产物，首要任务是快速释放空间：
--截断表
truncate table xxx;
--删除表
truncate table xxx;
drop table xxx;
可以drop表时，建议也先清理数据，再删表，数据释放会明显更快。
3.2 临时文件进程处理
临时文件名（如 pgsql_tmpPID.xxx）中 pgsql_tmp 后的数字即为本地节点（DN）的进程号，使用 ps 命令查看该本地进程的详细信息：
输出信息通常包含发起此会话的客户端连接信息（如来源 CN 节点 IP）和远端进程号 (PID)。例如，从上图可知，本地 DN 进程 9848 可能由 CN193 节点的 50343 进程发起，9846 由 CN193 节点的 50438 进程发起。
将pid 50343和50438拿到dn193上查询pg_stat_activity视图，查看会话信息：
select * from pg_stat_activity where pid in('50343','50438');
将查到的会话信息反馈给应用团队，由他们决定是否停止应用进程或终止会话。
4 总结
pg库磁盘空间问题虽然常见，但处理不当可能会导致严重的后果。通过检查当前活动会话、异常大表和临时文件，可以快速定位问题根源。在处理过程中，需要根据具体情况采取合理的措施，例如清理大表数据或终止异常会话。同时，开发人员应避免因操作失误（如笛卡尔积错误）导致此类问题的频繁发生。
最重要的是建立完善的监控机制，能够及时检测到磁盘增长异常情况，触发告警供dba处理。
