摘要：在某个深夜的紧急维护中，当您发现根目录剩余空间不足1%时；在持续构建失败却找不到原因时；当服务器响应速度突然变慢时——找到那些吞噬磁盘空间的"元凶文件"往往是解决问题的第一步。
在某个深夜的紧急维护中，当您发现根目录剩余空间不足1%时；在持续构建失败却找不到原因时；当服务器响应速度突然变慢时——找到那些吞噬磁盘空间的"元凶文件"往往是解决问题的第一步。
某电商平台数据库服务器突发IO阻塞，经排查发现是某个PHP进程持续写入的10GB错误日志文件。运维团队使用du -sh *逐层查找耗时27分钟，而使用本文介绍的组合命令仅需8秒即可锁定目标。
查看当前目录各子目录大小（人类可读格式）
du -h --max-depth=1 | sort -hr查找前10大目录（排除挂载点）
du -xh / 2>/dev/null | sort -rh | head -n 10进阶技巧：筛选大于500MB的目录
du -h --threshold=3M /etc 2>/dev/null查找/etc下大于1M的文件（精确到字节）
find /etc -type f -size +1048576 -exec ls -lh {} \; 2>/dev/null按时间维度搜索（最近30天修改过的500MB+文件）
find /var -mtime -30 -size +500M -printf "%s\t%p\n" | sort -n按文件大小逆序显示前20项（含隐藏文件）
ls -AlhS --group-directories-first | head -n 20显示inode使用情况（排查大量小文件问题）
ls -i | sort -n | tail -n 15按第5列（大小）数字逆序排序
du -h /etc | sort -k5 -hr混合排序：优先目录后文件，按大小降序
find . -type d -exec du -s {} \; 2>/dev/null | sort -n | cut -f2 | xargs du -sh查找实际占用小于表面大小的文件
find . -type f -printf "%S\t%p\n" | awk '$1定位快照中占用最大的COW块
lvs -o +devices,metadata_percent查找体积最大的容器层
docker system df -v | grep GB | sort -k5 -hShell脚本示例
#!/bin/bash ALERT_THRESHOLD=1073741824 # 1GB LOG_FILE="/var/log/big_files_$(date +%Y%m%d).log" find / -type f -size +${ALERT_THRESHOLD}c -exec ls -lh {} \; 2>/dev/null > ${LOG_FILE} if [ -s ${LOG_FILE} ]; then echo "发现超大文件！" | mail -a ${LOG_FILE} -s "磁盘空间警报" admin@example.com fiSystemd定时器配置
# /etc/systemd/system/disk-check.timer [Unit] Description=Daily disk space check [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target 禁忌与陷阱/proc与/sys目录的误判风险虚拟文件系统的特殊处理：
find /proc -size +100M # 永远返回空结果 NFS挂载点的性能雪崩使用-xdev避免网络遍历：
find /mnt/nfs -xdev -size +1G来源：wljslmz
