1. 磁盘空间告警后的第一反应收到服务器磁盘空间不足的告警时我的第一反应不是立即删除文件而是先搞清楚三个关键问题哪个分区快满了是什么类型的文件占用了空间这些文件是否可以被安全清理这种系统化的排查思路能避免误删重要数据。最常用的df -h命令就像汽车的油表能快速显示各分区的使用情况。我习惯加上-T参数显示文件系统类型因为不同的文件系统有不同的特性。比如看到xfs文件系统快满了要特别小心因为XFS文件系统在空间耗尽后更容易出现故障。# 查看各分区使用情况和文件系统类型 df -hT当发现/var分区使用率达到95%时我会先用cd /var进入该目录然后用du -sh * | sort -rh | head -10找出占用空间最大的前10个目录。这个组合命令中-s表示汇总大小-h以人类可读格式显示sort -rh按人类可读的数字逆序排序。2. 深入分析大目录内容找到大目录后需要像侦探一样层层深入。比如发现/var/lib/postgresql占用异常我会用--max-depth参数逐级下钻# 一级目录分析 du -h --max-depth1 /var/lib/postgresql # 二级目录分析 du -h --max-depth1 /var/lib/postgresql/12/main对于PostgreSQL的数据目录有几个关键子目录需要特别关注base/存储实际数据文件不能随意删除pg_wal/WAL日志文件可以配置自动清理pg_log/数据库日志文件需要定期归档我曾遇到过pg_wal目录暴涨的情况原因是主从复制中断导致WAL日志堆积。通过pg_controldata可以查看当前的WAL日志状态pg_controldata /var/lib/postgresql/12/main3. PostgreSQL数据库的专项清理当确定是数据库占用过大时需要区分是正常数据增长还是异常堆积。首先查看各数据库大小SELECT pg_database.datname, pg_size_pretty(pg_database_size(pg_database.datname)) as size FROM pg_database ORDER BY pg_database_size(pg_database.datname) DESC;如果发现某个表异常大可以用以下SQL查看表的大小含索引SELECT table_schema || . || table_name AS table_full_name, pg_size_pretty(pg_total_relation_size( || table_schema || . || table_name || )) as size FROM information_schema.tables WHERE table_schema NOT IN (pg_catalog, information_schema) ORDER BY pg_total_relation_size( || table_schema || . || table_name || ) DESC LIMIT 20;对于需要清理的大表TRUNCATE比DELETE更高效因为它不记录单行删除操作-- 清空表但保留表结构 TRUNCATE TABLE large_table; -- 清空表并重置自增序列 TRUNCATE TABLE large_table RESTART IDENTITY;4. 自动化监控与预防措施为了避免半夜被磁盘告警吵醒我设置了多层防护每天检查磁盘空间的cron任务#!/bin/bash THRESHOLD90 CURRENT$(df / --outputpcent | tail -1 | tr -d % ) [ $CURRENT -ge $THRESHOLD ] echo Warning: Disk usage is ${CURRENT}% | mail -s Disk Alert adminexample.comPostgreSQL的自动维护任务-- 设置自动清理参数 ALTER SYSTEM SET autovacuum on; ALTER SYSTEM SET autovacuum_vacuum_scale_factor 0.1; ALTER SYSTEM SET autovacuum_analyze_scale_factor 0.05; -- 限制WAL日志大小 ALTER SYSTEM SET max_wal_size 2GB; ALTER SYSTEM SET wal_keep_segments 32;日志轮转配置/etc/logrotate.d/postgresql/var/log/postgresql/*.log { daily missingok rotate 7 compress delaycompress notifempty sharedscripts postrotate /usr/bin/pg_ctl logrotate -D /var/lib/postgresql/12/main endscript }曾经有一次一个开发环境的数据库日志配置不当导致500GB的磁盘一周内被日志塞满。现在我会特别检查logging_collector和log_rotation_size参数的设置是否合理。
