1. 当根分区突然爆满时那天早上我刚到办公室就接到同事的紧急电话数据库连不上了登录服务器一看熟悉的/dev/mapper/vg_xxx-lv_root显示100%使用率。这种情况在运维工作中太常见了但每次处理都需要格外小心因为根分区爆满可能导致系统完全瘫痪。首先用df -h确认磁盘状态这是我们的第一道诊断命令。输出结果会显示各个挂载点的使用情况重点关注Use%列。当根分区爆满时系统会变得异常缓慢甚至无法执行基本命令。这时候千万别慌我们可以通过du -sh *来查看当前目录下各文件夹的大小分布。记得有次处理类似问题时我发现/var/log目录占用了30多GB空间原来是某个应用的调试日志没有配置轮转。这种问题看似简单但如果直接删除日志文件而不处理写入进程可能会导致更严重的问题。2. 系统化排查六大常见根因2.1 日志文件失控增长日志文件是最常见的磁盘杀手。除了常见的/var/log/messages、/var/log/syslog外这些位置也值得关注/var/log/journal/- systemd日志/var/log/nginx/或/var/log/apache2/- Web服务器日志/var/lib/docker/containers/- Docker容器日志处理日志时echo file.log比直接删除更安全特别是当进程仍在写入该日志时。对于MySQL的binlog正确的做法是登录MySQL执行PURGE BINARY LOGS BEFORE 2023-01-01 00:00:00;而不是直接删除文件。2.2 缓存文件堆积如山缓存文件经常被忽视但它们可能占用惊人空间/var/cache/- 系统包管理器缓存~/.cache/- 用户级缓存/tmp/- 临时文件我曾经遇到过一个案例/var/cache/yum占用了20GB空间原因是自动更新没有配置清理。使用yum clean all或dnf clean all可以安全清理这些缓存。2.3 Docker的隐藏空间占用Docker如果不加管理会悄悄吃掉大量磁盘空间悬空镜像docker image prune停止的容器docker container prune构建缓存docker builder prune卷docker volume prune一个有用的命令是docker system df它能清晰显示Docker各组件占用的空间。记得有次清理后回收了40GB空间都是长期积累的中间镜像。2.4 已删除但未释放的文件这是最隐蔽的问题之一。当文件被删除但仍有进程打开它时空间不会被释放。使用lsof | grep deleted可以找到这些僵尸文件。解决方法通常是重启持有这些文件的进程。2.5 Inode耗尽危机即使磁盘空间充足Inode耗尽也会导致磁盘已满错误。用df -i检查Inode使用率。大量小文件是罪魁祸首常见于邮件服务器或文档处理系统。解决方法包括合并小文件删除不需要的小文件必要时扩容文件系统2.6 挂载点覆盖问题当非空目录被挂载时原内容会被隐藏但仍占用空间。lsblk和mount命令能帮助识别这种情况。解决方法通常是先卸载处理原内容后再重新挂载。3. 安全清理的黄金法则3.1 清理前的必要准备在动手清理前这些准备工作能避免灾难备份关键数据通知相关团队可能的服务中断记录当前磁盘状态(df -h、du -sh /*等)确认有足够的权限我习惯在清理前先用ncdu工具进行可视化分析它能交互式地浏览目录大小比单纯的du更直观。3.2 分步清理策略按照这个顺序清理最安全有效首先清理临时文件和缓存然后处理日志文件接着检查应用程序特定数据最后考虑系统文件对于日志文件配置logrotate比手动清理更可持续。这是一个标准的logrotate配置示例/var/log/myapp.log { daily rotate 7 compress delaycompress missingok notifempty create 644 root root }3.3 预防胜于治疗建立预防机制比事后清理更重要设置磁盘使用率监控告警建议在80%时触发配置自动日志轮转定期执行清理脚本对Docker等易膨胀组件设置空间限制我常用的监控命令是df -h --outputsource,pcent | grep -v Use% | sort -k2 -n它能按使用率排序显示文件系统。4. 高级技巧与深度优化4.1 LVM空间扩展实战如果清理后空间仍不足LVM提供了灵活的扩展方案。基本步骤pvcreate /dev/sdX如果有新磁盘vgextend vg_xxx /dev/sdXlvextend -L 10G /dev/mapper/vg_xxx-lv_rootresize2fs /dev/mapper/vg_xxx-lv_root对ext文件系统记得有次线上扩容我忘了最后一步resize2fs结果虽然逻辑卷扩大了但文件系统没跟上闹了个笑话。4.2 自动化清理脚本这是一个我常用的安全清理脚本框架#!/bin/bash # 安全清理脚本 LOG_DIR/var/log CACHE_DIRS(/var/cache /tmp) echo 当前磁盘状态: df -h echo 清理旧日志... find $LOG_DIR -type f -name *.log.* -mtime 30 -delete echo 清理缓存... for dir in ${CACHE_DIRS[]}; do [ -d $dir ] find $dir -type f -atime 7 -delete done echo 清理后的磁盘状态: df -h4.3 文件系统选择优化对于特定场景选择合适的文件系统能减少问题XFS适合大文件Btrfs自带压缩和去重ZFS高级存储管理功能我曾经将一个频繁写入小文件的系统从ext4迁移到XFS不仅解决了Inode耗尽问题性能还提升了20%。5. 当所有方法都无效时如果经过全面清理空间仍然不足最后的解决方案包括迁移部分数据到其他存储增加新磁盘并挂载到特定目录彻底重建系统并优化分区方案有一次我遇到一个特别棘手的情况最终发现是某个数据库的临时文件配置错误将其指向专用存储分区后问题彻底解决。这提醒我们有时候最根本的解决方案是重新思考数据存储策略而不仅仅是技术层面的修补。