Linux磁盘空间排查与清理实战指南

1. Linux磁盘空间告急这些排查思路能救急上周服务器又报警了/var分区使用率突破95%。这种场景对运维来说太常见了——日志暴增、临时文件堆积、甚至是僵尸文件占用空间。今天分享一套我用了8年的排查组合拳从快速定位到彻底解决手把手带你疏通Linux的血管堵塞。先看两个必杀技df -h一眼看清各分区水位人类可读格式du -sh *快速揪出目录里的空间怪兽但真实情况往往更复杂。某次生产环境报警用df查看到根目录爆满但du统计所有子目录却少了20G空间——原来是某个进程删除了正在使用的日志文件导致空间未释放。这时候就需要lsof | grep deleted来找出这些幽灵文件。2. 空间排查三板斧df/du/lsof的黄金组合2.1 df命令你的空间仪表盘df -hT这个命令我每天要敲几十次。关键参数解析-h人类可读单位自动换算GB/MB-T显示文件系统类型ext4/xfs等--total末尾显示汇总行多分区时特别有用典型输出示例Filesystem Type Size Used Avail Use% Mounted on /dev/nvme0n1p2 ext4 200G 186G 14G 93% / tmpfs tmpfs 16G 0 16G 0% /dev/shm警告当Use%超过90%时就要立即处理某些服务如MySQL在磁盘满时会出现不可逆损坏。2.2 du命令空间分配侦探当df显示空间不足但不知道哪个目录占用的时就该du上场了# 查看当前目录各子目录大小 du -sh * | sort -h # 深度扫描耗时较长但更全面 du -h --max-depth1 / | sort -h实用技巧配合sort -h按人类可读数值排序倒序用-r使用--exclude跳过特定目录如--exclude*.log--time显示最后修改时间找老旧文件利器2.3 lsof处理空间消失术遇到过这种情况吗df显示空间已满但du统计却少了几十G大概率是文件被删除但进程仍持有lsof L1 | grep deleted输出示例java 12345 user 10u REG 253,0 8589934592 1234 /var/log/app.log (deleted)解决方法重启持有文件的进程最彻底清空文件内容truncate -s 0 /proc/12345/fd/10生产环境慎用3. 空间清理实战精准打击五大磁盘黑洞3.1 日志文件——沉默的空间杀手# 查找超过100MB的日志文件 find /var/log -type f -name *.log -size 100M -ls # 清空而不删除文件服务可能依赖文件描述符 truncate -s 0 /var/log/monster.log # 按时间清理删除7天前的日志 find /var/log -type f -name *.log -mtime 7 -delete进阶方案配置logrotate自动轮转示例配置/var/log/nginx/*.log { daily missingok rotate 14 compress delaycompress notifempty create 0640 www-data adm sharedscripts postrotate /usr/sbin/nginx -s reload endscript }3.2 临时文件——系统的垃圾抽屉重点检查目录/tmp/var/tmp用户家目录下的.cache应用特定临时目录如MySQL的/tmp/ib*安全清理方法# 使用tmpwatchRHEL系 tmpwatch 24h /tmp # 使用systemd-tmpfiles现代发行版 systemd-tmpfiles --clean3.3 软件包缓存——容易被忽视的囤积癖包管理器的缓存可能占用数GB空间# apt清理Debian/Ubuntu apt-get clean apt-get autoremove # yum清理RHEL/CentOS yum clean all dnf autoremove # pacman清理Arch pacman -Sc3.4 容器和镜像——虚拟化的空间代价Docker的磁盘占用经常失控# 查看磁盘使用详情 docker system df # 清理所有停止的容器、无用镜像和网络 docker system prune -a # 针对性清理保留最近镜像 docker image prune --filter until24h3.5 用户文件——意料之外的空间大户查找大文件三剑客# 查找大于500MB的文件 find /home -type f -size 500M -exec ls -lh {} \; # 按用户统计空间使用 du -sh /home/* | sort -h # 查找重复文件 fdupes -r /home4. 高级排查当常规手段失效时4.1 inode耗尽——另一种磁盘已满错误信息No space left on device但df -h显示有空间可能是inode用尽df -i # 查看inode使用情况 find / -xdev -type f | cut -d / -f 2 | sort | uniq -c | sort -n # 统计目录文件数解决方法删除小文件如邮件、缓存重建文件系统增大inode数量4.2 文件系统错误——隐藏的空间漏洞# 检查文件系统错误 fsck -y /dev/sda1 # 查看被保留的块通常占5% tune2fs -l /dev/sda1 | grep Reserved block count # 临时调整保留空间紧急情况下 tune2fs -m 1 /dev/sda1 # 设为1%4.3 LVM扩容——终极解决方案如果分区确实需要扩容LVM是最佳选择# 查看当前PV/VG/LV信息 pvdisplay vgdisplay lvdisplay # 扩展逻辑卷假设已扩充分区 lvextend -L 20G /dev/vg00/lv_root resize2fs /dev/vg00/lv_root5. 防患于未然空间监控自动化方案5.1 监控脚本示例#!/bin/bash THRESHOLD90 CURRENT$(df / --outputpcent | tail -1 | tr -d % ) if [ $CURRENT -ge $THRESHOLD ]; then echo WARNING: 根分区使用率 ${CURRENT}% echo TOP 5目录: du -h --max-depth1 / 2/dev/null | sort -h | tail -5 echo 可能的大文件: find / -type f -size 100M -exec ls -lh {} \; 2/dev/null | head -10 fi5.2 配置Prometheus监控node_exporter的报警规则示例groups: - name: disk.rules rules: - alert: DiskSpaceCritical expr: 100 - (node_filesystem_avail_bytes{mountpoint/} * 100 / node_filesystem_size_bytes{mountpoint/}) 90 for: 10m labels: severity: critical annotations: summary: 根分区空间不足 (instance {{ $labels.instance }}) description: {{ $labels.mountpoint }} 使用率 {{ printf \%.2f\ $value }}%5.3 日志轮转最佳实践建议配置按大小轮转如超过100MB保留固定数量备份如7个启用压缩节省50%空间敏感日志设置权限如600重要日志远程同步6. 血泪教训我踩过的那些坑rm -rf /var/log/* 的惨剧曾经在清理日志时误操作导致所有日志包括正在写入的被删除引发服务异常。现在改用truncate或echo file。ext4的保留空间某次紧急扩容时发现5%空间被保留用tune2fs -m 0临时释放后导致系统卡顿。后来才知道这是为root用户保留的应急空间。NFS挂载点的陷阱df显示空间不足实际是远程NFS服务器的问题。现在会先确认挂载点类型df -hT。LVM快照的空间爆炸创建快照时没估算好COW空间导致原卷性能骤降。现在遵循快照大小预期变化量×2原则。Docker的overlay2堆积发现/var/lib/docker占用异常后才知道要定期执行docker system prune。现在写进了日常维护脚本。