Linux磁盘空间占用排查实战：理解df与du，善用lsof与inode-北京尧图网络

1. 先搞清楚磁盘占用分析到底在解决什么问题日常运维和开发中最让人心头一紧的告警之一就是“磁盘空间不足”。我处理过很多次这种问题表面看只是df -h输出红了但背后原因五花八门可能是某个服务把日志写得停不下来可能是一个临时文件被进程持续写入但已经删除也可能是某个数据目录被备份脚本塞爆了。真正头疼的不是“磁盘满了”这个结果而是“空间去哪了”这个谜题。这篇内容适合所有跟Linux打交道的人看不管是刚入门的新手还是已经写了几年脚本的老手。新手可以通过这篇文章建立一个完整的排查思路不再拿到服务器就只会按方向键翻历史记录老手也可以对照一下自己的排查流程看看有没有遗漏的盲区。我尽可能把实际操作中的细节、容易踩的坑、以及那些文档里不会明说的经验都写出来。1.1 先建立一个基本认知df和du的差异很多人刚开始做磁盘占用分析时习惯一上来就执行du -sh *然后发现统计出来的总大小跟df -h显示的使用量对不上就开始怀疑是不是命令用错了。其实df和du的统计机制本身就不同理解它们的差异比会敲命令重要得多。df是从文件系统层面获取块设备的使用情况它统计的是整个文件系统的总块数、已用块数和可用块数这个数据来自文件系统自身的元数据。du则是通过遍历目录树逐个文件累加占用的块数来得到结果。两者统计维度不同天然会出现差异。差异来源主要有几个文件被删除但进程仍持有文件描述符时du已经看不到了但df会继续把空间算作已用文件系统预留的块比如ext系列默认预留5%也会造成两边数据不一致还有du默认不统计其他挂载点的内容而df是按每个挂载点单独显示的。我自己的习惯是先df看整体水位再用du定位大头。df告诉你是哪个分区出了问题du告诉你是哪个目录在搞事情。两条命令配合使用基本能解决90%的“磁盘满了”问题。1.2 分析前先摸清现场这些信息必须第一时间记录在动手清理之前先花两分钟把现场信息记录下来。这一步经常被忽略但在事后复盘和定位根因时非常有用。至少需要记录df -h的输出、df -i的输出inode使用情况、当前时间点、最近是否有部署或配置变更、是否有批量任务在跑。尤其是df -i的输出我见过不少“磁盘还有好几十G但就是写不进文件”的情况最后查下来是inode耗尽了。inode是文件系统用来保存文件元数据的数据结构每个文件或目录都要占用一个inode。当分区里文件数量极其庞大时即使还有剩余空间也会因为inode用完而无法创建新文件。这个问题在消息队列积压、邮件队列、小文件缓存这类场景里特别常见。我常用的快速记录方式是把这些信息直接追加到一个日志文件里带上时间戳方便后续回溯。命令大概是这样的{ echo $(date %F %T) df -h df -i echo ----- 最近24小时新增的大文件 ----- find / -xdev -type f -mtime -1 -size 100M -exec ls -lh {} \; 2/dev/null | head -50 } /var/log/disk_audit.log这段命令把df的快照和最近一天内新增的大文件都记录下来了排查时非常有用。注意-xdev参数告诉find不要跨文件系统这样能避免扫到/proc、/sys这些虚拟目录时产生大量无意义的输出。2. 从根目录开始的逐层下钻定位大目录和文件的实操方法拿到服务器后我一般不会直接du -sh /*因为有些挂载点可能很慢甚至会有网络文件系统挂在上面扫起来会卡住。更稳妥的做法是先看挂载情况再针对可疑的挂载点逐个排查。df -h mount | grep -v -E proc|sysfs|cgroup|devpts|tmpfs|overlay先看清楚哪些是真实存在的磁盘分区哪些是虚拟文件系统。虚拟文件系统不占实际磁盘空间排查时可以跳过。然后针对使用率比较高的分区从挂载点开始往下逐层定位。2.1 用du逐层定位大目录的操作细节假设/分区的使用率已经到95%我会执行du -h -x -d 1 / 2/dev/null | sort -rh | head -20这里几个参数都值得说一下。-h是human-readable以K、M、G为单位显示-x是one-file-system不跨文件系统这一点很关键避免把其他挂载点的空间也统计进来导致结果虚高-d 1是目录深度为1只看根目录下一级子目录的大小。-d参数比--max-depth写起来短效果一样。最后用sort按大小从大到小排取前20个。看到哪个目录是主要占用来源后再对那个目录执行同样的操作一层层往下钻。比如发现/var很大就执行du -h -x -d 1 /var 2/dev/null | sort -rh | head -20这样很快就能定位到具体是/var/log还是/var/lib还是/var/tmp在膨胀。这里有一个打包好的逐层下钻思路与其一次次手动敲命令不如写一个小循环每层自动找出最大的子目录并打印出来。我以前是直接在shell里套循环的后来发现写个递归的脚本更顺手在文章后面的章节我会贴一个完整版本直接把整条链路从上到下自动找出来。2.2 找大文件时的排序与过滤技巧目录定位到了但有时候一个目录里有海量文件直接用ls -lS排序可能因为文件太多而卡顿。这种情况下我用一条组合命令精准锁定find /var/log -xdev -type f -size 500M -exec ls -lh {} \; 2/dev/null | awk {print $5, $9} | sort -rh | head -30这条命令做了三件事找出/var/log下所有大于500M的普通文件格式化输出大小和完整路径按大小倒序排并取前30条。-size 500M这个阈值可以根据实际情况调整如果磁盘特别紧张可以降到100M甚至50M。另外日志目录里经常有带时间戳的轮转文件比如app.log.20250101、app.log.20250102这种。要快速统计这类文件占了多少空间可以按文件名模式聚合find /var/log -xdev -type f -name app.log.* -exec du -ch {} 2/dev/null | tail -1du -ch组合参数里的-c是总计-h是人类可读。tail -1取出最后一行总计值。这样能快速判断某个服务的日志轮转文件整体占了多少空间比一个个文件加起来方便得多。用户目录也是重灾区。/home下的每个用户目录我都习惯单独看一下find /home -xdev -mindepth 1 -maxdepth 1 -type d -exec du -sh {} \; 2/dev/null | sort -rh这样能一眼看出哪个用户是“空间吞噬者”。如果服务器上跑着多个Java应用或数据库实例数据目录、堆转储文件、错误日志都是大文件出现的常见位置排查时不要遗漏。3. 空间被占用但文件已删除lsof和日志文件的特殊处理这类问题是我在故障排查中遇到最多的一种“灵异事件”之一。表象很典型df -h显示某分区使用率高达99%但du -sh /*把所有目录大小加起来怎么算都只有50%左右空间莫名其妙“消失”了。如果你也遇到这种情况最可能的原因是有进程正在写入一个已经被删除的文件。Linux的文件系统机制是只要进程持有文件描述符即使文件已经通过rm从目录结构中移除磁盘空间依然被占用直到进程关闭该文件或进程结束。3.1 用lsof精准定位无法释放的空间定位这类问题lsof是绕不开的工具。以下是我常用的命令lsof L1 2/dev/null | sort -k7 -rh | head -30L1表示只显示link count为0的文件也就是已经被删除但仍有进程打开的文件。这里稍微解释一下link count是文件硬链接的数量当文件从目录中删除后硬链接数为0但如果有进程打开了它文件的数据块还没有真正释放。列出结果后关注SIZE列和COMMAND列能看出是哪个进程占用了多少空间。输出里还可能包含类似/path/to/file (deleted)的路径注意看(deleted)标记这就是阻塞空间的“元凶”。如果需要更精确地按目录筛选可以加上路径过滤。比如怀疑/var/log下的文件执行lsof L1 2/dev/null | grep /var/log或者按进程名过滤lsof L1 2/dev/null | grep -E java|nginx找到阻塞空间的进程和文件后处理方式有两种。如果服务允许重启直接重启服务文件描述符释放空间立即回收。如果不能重启服务可以对/proc/pid/fd/fd路径下的文件做空操作来释放空间。比如进程PID是1234文件描述符是5可以执行: /proc/1234/fd/5把该文件截断为空但保持文件描述符仍指向有效位置进程可以继续写入同时空间立即释放。这个操作比rm更优因为rm后进程仍然写一个不可见文件空间不会释放。这里特别提醒执行ls -l /proc/1234/fd/5可以查到实际文件路径和大小确认没问题再操作。3.2 日志截断的正确姿势别一删了之很多日志文件是长期被进程持有的比如Java服务用logback写的日志Nginx的access log和error logSupervisor管理的进程输出日志。这些日志文件即使被rm删掉进程还是会继续写入旧的文件描述符空间不会释放反而因为找不到原路径排查难度更大。正确的做法是截断而不是删除truncate -s 0 /var/log/nginx/access.log或者用重定向清空 /var/log/nginx/access.log清空后空间立即释放进程继续写入也是正常的。需要注意如果日志文件被Nginx自己重开过比如配置了定时轮转并reopen路径可能已经指向新文件这时候清空旧文件反而不必要。先lsof确认一下哪些进程持有它再决定怎么处理。另外即使进程持有文件截断后写日志的位置会从offset 0开始有些程序会因此出现日志空洞但概率很低绝大多数场景下无影响。如果日志中突然缺了一段时间不要慌检查是否有人对日志文件做过截断操作。我自己的习惯是发现日志文件过大时先看看有没有日志轮转配置没有的话立即配置logrotate然后再处理当前积累的大文件。一删了之只解决眼前问题没有轮转配置过几天还会再爆一次。4. 容易忽略的inode耗尽和挂载边界问题在磁盘占用分析中inode问题是一个容易被忽略但非常致命的方向。很多人在排查时只看磁盘空间等到确认空间还有几十个G、但创建文件失败时才意识到inode已经耗尽。4.1 inode耗尽的判断和处理流程先用命令确认问题df -i看IUse%这一列如果接近100%就是inode耗尽。导致inode耗尽的原因是文件数量过多比如大量的小文件、邮件队列积压、消息队列的临时文件没清理、ext文件系统的journal节点异常增长等。这些小文件可能只占很少的磁盘空间但每个都要占用一个inode。排查手段和定位大目录一样用find统计目录下文件数量find /var/spool -xdev -type f | wc -l如果文件数量特别巨大直接ls可能会卡死可以用find配合wc -l先统计数量级再决定从哪里开始清理。对目录逐层下钻找出文件数量最多的子目录可以用find /var -xdev -type d -exec sh -c echo $(find $1 -maxdepth 1 -type f | wc -l) $1 _ {} \; 2/dev/null | sort -rn | head -20这条命令会找出/var下文件数最多的20个目录帮助快速聚焦。清理时注意inode问题往往是数量问题而非大小问题所以删除策略要面向“减少文件数量”而不是“释放空间”。我遇到过一种情况一个队列目录下有60多万个JSON小文件每个只有几KB但硬生生把inode吃满了。清理时用find ... -delete比xargs rm -f更安全前者不会因为参数列表过长而失败find /var/spool/queue -xdev -type f -mtime 3 -delete4.2 文件系统边界挂载点下的真实占用排查磁盘占用时很多人没有意识到du和df对挂载点的处理差异。df按文件系统维度显示du按目录树遍历。如果在某个挂载点下面有了子目录的挂载那么父分区看到的子挂载目录大小其实是“空”的它的空间算在子分区的df报告里。我举个例子。/data是一个独立分区/data/mysql下又挂了一个单独的卷。在/分区里看/data目录du默认不会跨挂载点去统计/data/mysql的实际数据所以如果只看父目录的du结果会觉得空间“少”了。排查时要留意findmnt -rA | grep -v -E proc|sysfs|cgroup|devpts|tmpfs|overlay或者就是mount看一遍确认哪些路径下有独立挂载。如果分区的使用率异常高但du到挂载点时看不到大文件先看看这个挂载点下是不是还有子挂载。子挂载本身会把父目录的原内容“隐藏”掉父目录下实际的数据可能已经被覆盖这种场景需要特别小心。磁盘占用分析里的“边界”问题不只是挂载点。还有一个常见坑是在根文件系统下执行du -sh /时把/proc、/sys这类虚拟文件系统也扫了进去虽然它们不占实际磁盘但遍历它们会花费大量时间还可能输出各种无意义的错误。因此我习惯在du和find命令中始终带上-x或-xdev参数效果是告诉命令不要跨文件系统边界避免了把虚拟文件系统也纳入统计。5. 日志、缓存和临时文件的清理实践排查完大目录、处理完被占用的文件、修完inode问题接下来要考虑的是建立长效机制尤其是日志、缓存和临时文件这三类最常见的“空间杀手”。5.1 journald日志的快速增长和控制方法使用systemd的Linux发行版systemd-journald会持续记录系统日志。这个日志的默认大小配置在很多系统上偏宽松日积月累可能占掉好几个G。我记得遇到过一台Ubuntu服务器/var/log/journal直接吃掉了5G多的空间查了半天才发现是journal没限制。查看当前journal占用journalctl --disk-usage立即清理journalctl --vacuum-size200M journalctl --vacuum-time7d前者把journal压缩到200M以内后者清理7天之前的日志。如果想永久限制journal大小编辑/etc/systemd/journald.conf找到SystemMaxUse这一项取消注释并设置为合理值比如SystemMaxUse300M改完后重启服务使配置生效systemctl restart systemd-journald实际测试中SystemMaxUse生效后journal会自动轮转和清理历史日志不会再无限增长。这个配置对长期运行的服务器非常有用。5.2 logrotate的正确配置和排障日志轮转是Linux运维的基础技能但配置不当也会出各种问题。最典型的情况是配置了logrotate但copytruncate参数用得不对导致日志文件被截断后进程写入的位置错乱或者轮转不生效。一个相对稳妥的配置示例比如Nginx日志轮转/var/log/nginx/*.log { daily rotate 14 compress delaycompress missingok notifempty create 0640 nginx adm sharedscripts postrotate [ -f /var/run/nginx.pid ] kill -USR1 cat /var/run/nginx.pid endscript }这里解释几个关键参数。daily是每天轮转一次rotate 14保留14个归档文件compress对归档文件做gzip压缩delaycompress延迟一天再压缩这样昨天日志仍然可以方便地查看postrotate会在轮转后给Nginx发送USR1信号让它重新打开日志文件确保不中断日志写入。如果服务本身不支持重开日志只能靠copytruncate参数它的原理是先复制日志文件再清空原文件。这个方案虽然兼容性好但会丢失少量日志内容在复制和截断之间写入的数据而且如果日志量很大并且频繁轮转copytruncate对性能有一定损耗。配置完可以手动触发一次做验证logrotate -v /etc/logrotate.conf-v参数输出详细过程能看出有没有报错。如果日志没有按预期轮转检查以下几个方面配置文件是否有语法错误、dateext是否与rotate天数配合得当、定时任务是否生效/etc/cron.daily/logrotate是否存在且可执行、日志文件属主权限是否允许轮转。5.3 包管理器和临时目录的定期清理apt、yum、dnf这些包管理器在安装和升级时会下载大量缓存。Debian/Ubuntu系统执行apt-get clean apt-get autoremove --purgeRHEL/CentOS系统执行yum clean all dnf clean all这些缓存看似不起眼积攒久了也能占用数G空间。对于长期运行的服务器我建议把清理加入定时任务每月执行一次避免缓存无限膨胀。临时目录/tmp和/var/tmp也需要关注。/tmp通常有系统自动清理机制但/var/tmp保留的是长时间需要存在的临时文件很多应用会往里写入临时数据。如果担心误删可以按mtime时间戳来清理比如删除7天前的文件find /var/tmp -xdev -type f -mtime 7 -delete find /var/tmp -xdev -type d -empty -delete第二条命令把空的子目录也清除掉避免目录越积越多。6. 一键诊断把整个排查流程固化成脚本排查思路讲了不少实际应用中把这些经验固化成脚本能省很多事。我自己写了一个简易的磁盘占用诊断脚本思路很简单先看df和inode水位再列出最大的目录然后定位大文件和已删除但仍被占用的文件。这里贴一个精简版本#!/bin/bash # 磁盘占用快速诊断脚本 # 用法: ./disk_audit.sh [挂载点] MOUNT_POINT${1:-/} DATE_TAG$(date %F %T) echo 磁盘空间概览 ($DATE_TAG) df -h $MOUNT_POINT echo echo inode 使用情况 df -i $MOUNT_POINT echo echo 一级子目录空间占用 Top 10 du -h -x -d 1 $MOUNT_POINT 2/dev/null | sort -rh | head -10 echo echo 大于 500M 的文件 Top 20 find $MOUNT_POINT -xdev -type f -size 500M -exec ls -lh {} \; 2/dev/null | awk {print $5, $9} | sort -rh | head -20 echo echo 已删除但仍被进程占用的文件 lsof L1 2/dev/null | awk NR1 || $7 1048576 | sort -k7 -rhop使用方法也很简单比如要排查根分区直接执行./disk_audit.sh /排查/var分区执行./disk_audit.sh /var。脚本会自动输出五个维度的信息覆盖磁盘水位、inode水位、目录大头、大文件和空间泄漏五类问题。这里解释一下最后一条lsof的awk过滤条件$7 1048576表示只显示SIZE列大于1MB的被删文件避免太小不值得关注的记录刷屏。如果你用-o参数指定了输出字段列位置可能不同需要根据实际输出调整$编号。6.1 告警阈值建议与定时巡检脚本定位问题本身已经完成了大半但如果每次都要等到磁盘满了才跑脚本那运维体验还是太被动。我建议把这个脚本接入定时任务比如每天凌晨跑一次并把结果追加到日志文件供后续回溯。0 2 * * * /usr/local/bin/disk_audit.sh / /var/log/disk_audit.log 21同时做一个简单的告警判断比如空间使用率超过85%或者inode使用率超过90%时触发提醒。要注意df -h输出中最后一行是整体使用情况处理起来并不方便我通常用df -P加awk来提取数值列做判断。提取时注意多块磁盘的情况可以去掉-h参数用-P固定输出格式数值也是以KB为单位的纯数字方便计算df -P $MOUNT_POINT | awk NR2 {if ($50 85) print 磁盘空间告警: $5}inode的告警类似用df -Pi输出inode情况同样用awk判断。6.2 关于自动清理脚本的边界思考看到这里可能有人会问既然诊断脚本能跑能不能再写一个自动清理脚本把日志、临时文件、缓存一键清掉我的建议是谨慎。自动清理的风险在于“误删”。比如脚本里如果包含find /var -type f -mtime 7 -delete这样一刀切的逻辑很可能把正在使用的PID文件、socket文件或者某个应用精心生成的配置删掉。一旦服务起不来损失远超磁盘空间本身。我的经验是诊断自动化、清理半自动化。自动化负责发现问题并通知人人确认后执行清理操作。如果服务器规模大、出问题的频率高可以先把“清理”动作限定在明确安全的范围内比如journald日志它自带系统级保障、包管理器缓存最多重新下载、明确的归档目录等。对待有业务含义的数据文件始终保留人工确认环节。7. 常见问题速查表与排查口诀把前面讲的排查经验整理成一张速查表方便遇到问题时快速定位。以下是我自己在实际支持中经常对照的表格现象可能原因首选排查命令推荐处理方式df显示使用率超高du统计相差很大文件被删除但进程未释放lsof L1重启进程或截断/proc/pid/fd/fd磁盘还有空间但创建文件报No space leftinode耗尽df -i清理小文件、调整inode策略journal相关目录持续增长journald未限制大小journalctl --disk-usage配置SystemMaxUse日志目录持续膨胀缺少logrotate配置ls -lh /var/log为对应服务配置logrotate某个目录空间突然暴涨服务异常或临时文件堆积du -h -x -d 1 目录定位子目录后清理磁盘使用率忽高忽低可能是缓存或临时文件被定时清理观察df时间序列结合cron任务和脚本审计排查时我习惯记一句口诀先看水位再找界碑确认文件锁修完记得配。“水位”就是df和df -i的整体使用情况“界碑”指挂载点边界“文件锁”指被进程占用的已删除文件“修完配”是提醒自己处理完眼前问题后把日志轮转、告警阈值配好。这十六个字基本覆盖了90%场景的排查路径。8. 最后分享两个小技巧唠叨了这么多最后把我实际踩过坑、也最想推荐的两个小技巧写出来。第一个是关于du的进度问题。当服务目录特别大时执行du会扫描很久看起来像卡死了。其实du是在正常工作只是没有进度提示。如果等得着急可以在另一个终端用lsof | grep du看它在读哪些目录或者直接开-v参数看输出。不过更实用的方式是对有问题的目录做并行化扫描。du本身是单进程的但可以find /var -xdev -mindepth 1 -maxdepth 1 -type d -print0 | xargs -0 -P 4 -I {} du -sh {}-P 4表示4个进程并行统计速度快不少。但要注意并行du对IO压力的影响如果服务器本身负载已经很高并行会加剧磁盘争抢。第二个是关于大文件搜索的-size单位。find的-size参数中c表示字节k表示KBM表示MBG表示GB默认单位是512字节的块。新手最容易犯的错是写-size 500M发现没匹配到任何文件其实不是没大文件而是正在搜索的文件都不到500M。可以先放宽阈值比如-size 100M试一遍再逐步收紧。工具和方法本身都不复杂复杂的是在出问题时快速判断该用哪一把钥匙。多测多积累遇到类似问题就有感觉了。

Linux磁盘空间占用排查实战：理解df与du，善用lsof与inode

相关推荐

PaddleOCR Text Gestalt 文本图像超分辨率算法：从论文原理到训练、评估与推理部署实战

NDIS 6驱动zip包安装与排错全指南

Supabase 怎么在 Postgres 中用 Vault 存储加密密钥并在 SQL 中引用？

更多资讯

curl/libcurl CURLOPT_CAINFO 完整指南：CA 证书包路径设置与 TLS 校验原理

使用 Trainer API 进行超参数搜索：Transformers 内置 HPO 实战指南

Windows 部署 vLLM 实战：跑通 Qwen3-8B-FP8 本地推理服务的完整指南

AI生成图片如何被机器一眼识别？从标识校验到像素取证的技术机制

构网型逆变器控制：下垂控制与虚拟同步机仿真对比

FinceptTerminal FinAgent Core 深度解析：基于 Agno 框架的单一可配置金融 Agent 系统

今日更新

CopilotKit Vue Demo 与 React Demo 的 Parity 实现指南：路由、运行时端点与交互语义的全框架对齐

Harbor RBAC 实战：db_auth 模式下非管理员用户管理项目成员的完整验证与权限模型解析

STM32平衡车纯平衡程序从拆包到参数整定的完整调试指南

本周精选

超人会飞不算本事：系统稳定依赖清晰规则与边界设计

超人VS蜘蛛侠：拆解超级IP的影响力与传播方法论

基于CNN的调制信号识别：MATLAB实现时频图分类实战

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？