1. 磁盘空间告警的紧急响应凌晨3点服务器监控突然发出刺耳的警报声——/data分区使用率突破95%阈值。这种场景对于Linux运维人员来说再熟悉不过但处理不当可能导致服务雪崩。我立即通过SSH连入服务器首先确认问题范围df -hT输出显示/dev/sdb1的xfs文件系统确实已达100%利用率。此时切忌盲目删除文件正确的第一步是确认是否为伪满盘——即inode耗尽导致的假性空间不足df -i当inode使用率正常时本例中仅4%我们面临的是真实的磁盘空间危机。此时需要快速定位空间占用源头但直接使用du -sh *在全盘扫描可能耗时数小时。我的经验是采用分层排查法首先扫描一级目录大小du -hd1 / | sort -rh发现/data目录异常后逐层深入du -hd1 /data | sort -rh最终定位到某个具体的大文件或目录关键技巧在大型存储系统中添加--time参数可显示文件修改时间帮助判断文件价值du -hd1 --time /data/logs2. 隐藏的空间杀手已删除未释放的文件上周处理的生产事故中du显示仅占用200GB但df却报磁盘已满。这种矛盾现象往往意味着存在幽灵文件——已被删除但仍在被进程占用的文件。通过lsof工具可以揪出这些隐藏杀手lsof | grep deleted输出会显示类似如下的记录java 12345 user 12u REG 8,17 2147483648 1024 /var/log/app.log (deleted)此时有两种解决方案优雅重启相关进程推荐systemctl restart application.service紧急情况可清空文件内容 /proc/12345/fd/12血泪教训某次我直接kill -9了进程导致业务数据丢失。建议先确认进程重要性或至少保留core dump。3. 高效扫描工具选型与实践当面对TB级存储时传统du命令的扫描速度令人崩溃。经过多次对比测试我总结出以下工具矩阵工具安装方式优势劣势适用场景ncduapt install ncdu交互式界面可视化分析扫描大目录较慢中小规模目录分析gdugo install du/v4/cmd/gdu多线程扫描速度极快无交互界面快速扫描TB级存储dustcargo install du-dust树状展示直观显示占比结果排序不够灵活展示目录结构baobabapt install baobab图形化展示适合桌面环境需要GUI支持个人电脑分析以gdu为例的实战命令# 扫描并显示前20个大文件 gdu -n 20 /data # 排除特定目录如挂载点 gdu -x /data/nas4. 日志文件与临时文件的治理方案分析显示80%的磁盘爆满事故源于日志和临时文件。这里分享我的自动化治理方案日志轮转配置/etc/logrotate.d/自定义/var/log/app/*.log { daily rotate 7 compress delaycompress missingok notifempty create 644 appuser appgroup postrotate systemctl reload app.service endscript }tmpwatch自动清理RHEL系# 清理7天未访问的临时文件 tmpwatch --mtime 7d /tmp系统级监控脚本示例#!/bin/bash THRESHOLD90 PARTITION/data usage$(df --outputpcent $PARTITION | tail -1 | tr -d % ) if [ $usage -ge $THRESHOLD ]; then # 自动触发清理流程 find /data/logs -type f -name *.log.* -mtime 30 -delete systemctl restart logging-service fi5. 高级诊断文件系统级排查当常规手段无效时需要深入文件系统层排查。最近遇到的一个典型案例磁盘显示已满但找不到大文件。最终发现是稀疏文件(space file)作祟# 检查稀疏文件 ls -lsh large_file.bin # 输出中的第一个数字显示实际磁盘占用 # 8.0G -rw-r--r-- 1 root root 100G Jun 1 10:00 large_file.bin处理方案# 将稀疏文件转为真实占用 fallocate -d large_file.bin # 或彻底释放空间 truncate -s 0 large_file.bin另一个隐藏陷阱是docker容器日志。某次事故中发现/var/lib/docker/overlay2占用了300GB空间解决方案# 查看容器日志大小 docker ps -q | xargs docker inspect --format{{.LogPath}} | xargs ls -lh # 限制日志大小全局配置 cat /etc/docker/daemon.json { log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }6. 长效预防机制建设经过多次深夜救火后我建立了系统性的预防体系监控增强# 实时监控脚本加入crontab #!/bin/bash ALERT_EMAILadminexample.com df -h | grep -vE ^Filesystem|tmpfs|cdrom | awk { print $5 $6 } | while read output; do usep$(echo $output | awk { print $1} | cut -d% -f1 ) partition$(echo $output | awk { print $2 } ) if [ $usep -ge 90 ]; then echo Running out of space \$partition ($usep%)\ on $(hostname) | mail -s Disk Space Alert: $usep% used $ALERT_EMAIL fi done自动化清理策略# 使用systemd timer定期执行 [Unit] DescriptionWeekly disk cleanup [Timer] OnCalendarweekly Persistenttrue [Install] WantedBytimers.target架构优化实践日志集中收集到ELK集群临时文件使用tmpfs内存盘大容量存储采用LVM动态扩容关键分区设置quota限制每次磁盘空间告警都是一次系统健康检查的机会。上周通过分析某次报警我们发现了一个长期存在的内存泄漏问题——服务进程持续写core dump文件却未自动清理。建立完善的监控预防体系才能从根本上减少救火事件的发生。