# Linux 磁盘空间爆满怎么办？df、du 命令与日志清理实战

生产环境中遇到 Linux 磁盘空间爆满，往往是运维深夜报警的源头。处理这类问题，关键不是盲目 `rm -rf`，而是用 df、du 配合查找命令快速定位并安全清理。本文不罗列命令，只还原一套实战中验证过的排查路径：先从分区整体占用率开始，再逐步拆解到目录和文件，最后处置那些“已删却未释放”的隐形占用。

## 磁盘爆满前的快速诊断：用 df 命令检查分区使用率

磁盘告警的第一反应是确认是哪个分区撑不住了，以及到底是用光容量还是用光了 inode，这两者对应的处理方式完全不同。`df` 是这份诊断的起点，但它能给出的信息远比“使用率 90%”要多，只是大多数人只看一个百分比就急着动手。

### 如何一眼看懂 `df -h` 的输出？

`df -h` 的输出里，Size、Used、Avail 和 Use% 四列构成核心线索。Use% 达到 100% 时，Avail 通常已经降到极低，但不一定是 0——ext4 等文件系统有默认 5% 的保留块，root 用户之外写不进去。很多人忽视的是“Mounted on”这一栏，当 / 分区写满时，类似 VS Code Remote Server 这类通过 SSH 安装的服务会直接失败，报错大概率指向磁盘空间不足，这就是 df 信息最直接的应用场景。

### 哪个分区满了？为什么 df 和 du 的结果对不上？

用 `df` 定位到 / 或 /var 分区使用率接近 100% 后，下一步通常是用 `du -sh /* | sort -hr` 逐层排查。但在这里，多数人会遇到一个反直觉的坑：`df` 显示已用 100GB，`du` 遍历所有文件总和只有 60GB。差距的源头往往是已被 `rm` 删除、但被进程继续持有文件句柄的大文件。一个典型场景是运维删掉了 nginx 的 access.log，但 nginx 仍在往同一个 inode 写入，`df` 不会释放空间。这时候需要的不是继续 `du`，而是 `lsof +L1` 把那些“已删未释放”的文件揪出来。

### inode 耗尽了吗？当磁盘未满却无法新建文件时怎么办？

磁盘空间还有几百 MB，应用却报“No space left on device”，大概率是 inode 在作祟。`df -i` 能直接看到 inode 使用率，尤其是 /var/spool/mail 这类目录下，邮件队列堆积大量 0 字节文件，很容易在容量还很充裕时就把 inode 用光。这种情况下删大文件毫无意义，正确的动作是找到那些巨量小文件所在的目录，用 `find` 按文件数量而非容量来清理。在容器宿主机上，/tmp 或 /var/lib/docker/overlay2 里的碎片小文件同样是 inode 耗尽的重灾区。

## 精准定位大文件：du 命令查找目录与文件大小

`df -h` 告诉你哪块分区快满了，但它给的是宏观账本。真正的侦察工作，得靠 `du` 一层层扒开目录结构。这两个命令的组合，在运维圈有个很形象的比喻：df 是卫星云图，只能看到暴风雨在哪个区域聚集；du 是地面侦察，告诉你具体哪栋楼的哪个房间漏水了。

从实际排障经验来看，磁盘空间告急 80% 的场景都能用下面这几个 du 组合拳快速定位。剩下的 20% 是那些已经被 rm 删除但进程还抓着不放的“幽灵文件”——那是 lsof 的活，先不展开。

### 用 `du -sh *` 逐层排查，比全局扫描高效得多

新手常犯的错误是直接跑 `du -sh /`，等着十几分钟后回来一看，发现给 /proc 和 /sys 这类虚拟文件系统的报错淹没了。正确的做法是从分区根目录开始逐层深入：先 `du -sh /* | sort -hr` 看哪些一级目录在抢空间，锁定目标后再 cd 进去重复这个命令。

一家跨境电商公司的真实案例：开发环境磁盘从 72% 涨到 94% 只用了四十分钟。运维用这个办法在不到两分钟内定位到了 `/var/lib/docker/overlay2` 下的一个容器层，里面躺着 47GB 的 debug 日志。根本原因是 CI 流水线中的某个容器配置了 `restart: always`，而应用本身没有设置日志轮转策略。如果你不想等出问题再救火，一个经过实战检验的做法是定期用 `du -sh /var/* /tmp/* /home/*` 做快照对比，比盯着监控仪表盘更能发现缓慢膨胀的隐患。

### `du -a` 配合 `sort -rn` 能直接揪出“罪魁祸首”，但有两个陷阱

当目录层级太深或者需要找出所有大文件时，`du -a /path | sort -rn | head -20` 是标准解法。它会递归列出所有文件和目录的大小，按降序排列，前几名通常就是你要找的东西。但这个用法有两个很容易踩的坑。

第一个坑是性能。在文件数量超过 10 万级的目录（比如某个图片缓存目录或者邮件队列）里跑 `du -a`，磁盘 IO 会被瞬间拉高，直接影响线上服务。生产环境下更稳妥的做法是先设定一个阈值，用 `find /path -type f -size +500M` 筛出大个头，再针对性地分析。第二个坑更隐蔽：`du` 统计的是文件占据的实际磁盘块大小，与 `ls -l` 显示的逻辑大小可能不同。稀疏文件（比如某些虚拟机镜像或数据库的预分配空间）的逻辑大小可能是 100GB，实际占用可能只有 10GB。判断时需要交叉验证。

### 结合 find 搜索超限文件，记住把虚拟文件系统排在外面

`find` 和 `du` 是排查组合里的黄金搭档。最实用的组合是：先用 `find / -xdev -type f -size +100M` 限制在同一个文件系统内搜索，再通过 `-exec du -sh {} \;` 输出可读的大小。`-xdev` 这个参数格外重要，它能防止 find 跨入 /proc、/sys、/dev 这些虚拟挂载点，同样也能避免 NFS 挂载的远程目录被意外扫描——这种误操作曾导致某 SaaS 公司的一次故障排查演变成了跨国专线带宽打满的乌龙。一个值得记住的生产级命令模板是：

```
find / -xdev -type f -size +100M -exec ls -lh {} \; 2>/dev/null | sort -k5 -hr
```

这条命令会按文件大小从高到低列出所有超过 100MB 的常规文件，不碰虚拟文件系统，也不会漏掉隐藏在深层目录里的日志备份或数据库 dump 文件。定位到目标后，要不要删、怎么删，那是下一步的判断，但至少你已经知道敌人在哪儿了。

## 日志文件清理实战：从系统日志到应用日志

定位到磁盘占用大户后，真正的考验在于如何安全、彻底地释放空间。相较于直接删除文件，理解日志系统的运行机制更能避免“删了等于白删”的尴尬局面。

### journalctl 清理 systemd 日志：别碰二进制文件

systemd 的日志以二进制格式存储在 `/var/log/journal/` 下，直接 `rm` 删除目录内的文件是常见操作，但结果往往令人困惑——磁盘空间并未释放。原因在于 journald 守护进程持有这些文件的句柄，删除操作仅移除了目录项。正确的做法是使用 journald 自带的清理指令：`journalctl --vacuum-size=500M` 将日志总量控制在 500MB 以内，或 `journalctl --vacuum-time=2weeks` 仅保留最近两周的记录。在一台运行了 18 个月的测试服务器上，仅此一步就释放了 3.2GB 空间，且不影响 systemd 的日志写入功能。需要特别注意，这个机制独立于下文的 logrotate，两者管理的是完全不同的日志体系。

### logrotate 配置自动轮转：多数故障源于“我以为配了”

`/etc/logrotate.d/` 目录下躺着 nginx、mysql 等服务的轮转配置，但“存在配置”和“配置生效”之间隔着一个常见盲区。以 Nginx 为例，默认配置通常包含 `rotate 52`（保留 52 周）和 `compress`（压缩归档），但缺少 `maxsize` 限制——这意味着在日志量突增的场景下，单文件可能在轮转前就已膨胀到数十 GB。一个更务实的配置思路是增加 `maxsize 500M` 和 `daily` 的组合约束，同时把 `rotate` 缩减到 7 到 14 天。对于容器化环境，这条规则需要延伸：Docker 容器的 stdout/stderr 日志默认写入 `/var/lib/docker/containers/<id>/<id>-json.log`，它们完全不受宿主机的 logrotate 管理，必须在容器启动参数或编排文件（如 docker-compose.yml）中通过 `max-size` 和 `max-file` 显式限制。

### 手动删除 .log 文件的隐藏规则

当上述机制无法快速止血时，手动介入是必要的。但 `rm -f /var/log/app/*.log` 这个动作存在一个几乎反直觉的陷阱：如果目标文件正被某个运行中的进程以追加模式写入，`rm` 仅删除文件名，进程持有的文件描述符会让磁盘块继续被占用，`df -h` 上的使用率纹丝不动。验证方法是用 `lsof +L1` 列出所有被删除但仍被进程持有的文件——这些就是“幽灵空间”。正确的释放方式是用重定向清空而非删除：`> /var/log/app/access.log` 会立即将文件大小归零，同时不中断进程的写入流。如果已经执行了 `rm`，要么重启对应的进程，要么通过 `lsof | grep deleted` 找到进程 PID 后，在 `/proc/<pid>/fd/` 下找到对应文件描述符并执行 `> /proc/<pid>/fd/<fd_number>` 清空。后者属于应急方案，生产环境优先考虑重启或日志重载。

## 临时文件与缓存清理：释放潜在的大块空间

很多运维人员习惯先用 `df -h` 定位磁盘压力，再用 `du -sh /*` 逐层下钻，最终把焦点锁定在 `/var/log`。但实际场景中，临时文件和系统缓存才是更隐蔽的“黑洞”——它们不易被常规的日志轮转覆盖，却能在不知不觉中吞掉数十 GB 空间。

### 清理 /tmp 目录：不止是 `rm` 这么简单

`/tmp` 的清理陷阱在于：你看到的只是文件，但进程可能正握着文件句柄不放。一个典型例子是长时间运行的 Python 脚本写入的临时数据，即使借助 `tmpwatch --mtime 10 /tmp` 清理，仍可能被 `df` 与 `du` 的差异耍得团团转。更稳妥的做法是先用 `lsof +L1` 查看已删除但仍被占用的文件，确认没有关键进程依赖后，再用 `systemd-tmpfiles --clean` 统一回收。这个习惯可以避免“清完不见效”的挫败感。

### apt/yum 缓存清理：别让安装包吃掉根分区

Debian/Ubuntu 系下的 `/var/cache/apt/archives` 和 RHEL/CentOS 系下的 `/var/cache/yum` 是长期运行的系统极易忽略的死角。一条 `apt clean` 或 `yum clean all` 就能回收数百 MB 至数 GB 空间，特别是在频繁执行安全更新的服务器上。但真正值得注意的，是容器化环境下，包管理器的缓存可能被反复拉入镜像层，最终在宿主机上形成残留。此时，单机清理之外，还需要检查 `/var/lib/docker/overlay2` 这类目录，将 `docker system prune` 纳入日常巡检。

### Docker 镜像与容器清理：周期性 `prune` 而非救火

Docker 的磁盘占用从来不是一个“镜像大小”就能算清的账。容器日志文件默认被写进 `/var/lib/docker/containers/<id>/<id>-json.log`，且不受宿主机 `logrotate` 管理。如果一个容器持续打印标准输出而从未配置 `max-size` 和 `max-file`，日志很可能会膨胀到根分区报警。对于这种情况，单独删除日志文件只是治标，必须通过 `docker inspect` 确认日志驱动配置，再执行 `docker system prune -a --volumes` 清除未使用的镜像、容器和卷。需要注意的是，`--volumes` 会连带删除具名卷，生产环境建议先备份，或者分步执行 `docker container prune`、`docker image prune` 来降低风险。把这套逻辑写成定时脚本，比半夜被告警叫醒更划算。

## core dump 与邮件队列隐藏的磁盘吃痕

多数人排查磁盘爆满时，直觉是钻进 `/var/log` 里翻日志，但有两个更低调的“吃磁盘”大户常被忽略：一个是应用崩溃留下的 core dump，另一个是邮件队列堆积引发的 inode 耗尽。前者动辄几十 GB，后者能在磁盘还剩余大量空间时就让系统拒绝创建新文件——两者的破坏路径截然不同，却同样能以极快速度把运维拖进救火模式。

### core dump 文件藏在哪里？

过去 core dump 默认散落在应用的工作目录，systemd 接手后统一收敛到 `/var/lib/systemd/coredump/`，但前提是 `coredump.conf` 里没被随手禁用。我们见过一家跨境电商的后台服务，Java 进程因 OOM 反复崩溃，两周内在该目录下累积了 140GB 的 dump 文件，而监控只盯着 `/data` 分区，直到 `/var` 被撑满才触发告警。定位时优先用 `coredumpctl list` 看时间与大小，再配合 `find /var/lib/systemd/coredump -type f -size +100M` 捞出具体文件。如果没有调试需求，直接 `coredumpctl vacuum 3d` 清理三天前的转储，比 `rm` 更符合 systemd 的管理逻辑。对于仍沿用旧路径的应用，记得用 `sysctl kernel.core_pattern` 确认写入位置。

### mail spool 过大怎么处理？

另一种隐蔽故障是 `df -h` 还有空间，但 `df -i` 显示 inode 使用率 100%。根因多半是 `/var/spool/mail` 下堆积了数十万甚至上百万封邮件小文件，每一封只占几 KB，却消耗一个 inode。这类场景常见于：cron 任务输出未重定向，系统不断给 root 发送邮件；或 Sendmail/Postfix 队列配置失误，退信尝试反复投递，目录下滋生海量文件。某出海 SaaS 团队曾因此在凌晨被 inode 耗尽打穿业务，事后统计该目录下文件数超过 200 万，仅清理就用了将近 20 分钟。处理时先用 `find /var/spool/mail -maxdepth 1 -type f | wc -l` 确认数量，若队列无用可直接清空——但别直接用 `rm -f *`，参数列表太长会报错，改用 `find /var/spool/mail -type f -delete`。同时排查是谁在大量投递：`mailq` 看队列，`grep 'cron' /var/log/syslog` 查找重复调用，最后在 crontab 里加上 `>/dev/null 2>&1`，从根本上断了源头。

### lsof +L1 查找已删未释放文件

即便以上两点都排除了，仍会出现最让人困惑的一幕：`df -h` 显示使用率 90% 以上，`du -sh /*` 的总和却最多 60%。缺口来自那些已被 `rm` 删除、但文件句柄仍被进程持有的文件。国内一家游戏公司的日志清理脚本很勤快，每天凌晨准时 `rm` 掉 200GB 的 nginx access log，可 `df` 空间纹丝不动，原因正是 nginx 的 worker 进程还在向已删除的 inode 持续写入。这种场景下，`lsof +L1` 的价值无可替代——它直接列出链接计数为 0 的打开文件，再用 `lsof -p <pid>` 追到进程名和路径。如果占用者是容器里的日志写入进程，需要通过 `docker inspect` 找到容器 ID，或用 `/proc/<pid>/fd/1` 的软链接进行确认。恢复空间最干净的方式是重启持有句柄的进程，但风险需要评估：业务侧的热更新机制是否允许重启，写入内容是否有对应的备份策略。实在无法中断业务，也可以采取折中手段，比如对 fd 执行 `> /proc/<pid>/fd/1` 做清空，但务必先备份该 fd 所指向的内容，避免在未知文件上直接写入。根据阿里云监控团队的一份公开统计，线上磁盘告警中约 17% 的根因最终指向此类“已删未释放”文件，搞清楚这套排查链路，等于堵住了磁盘排查里最隐蔽的那个水位线。

## 预防再次爆满：长期监控与报警方案

磁盘空间告急从来不是一次性事件，只要线上业务还在跑，日志和临时文件就会持续产生。真正解决问题的方法，不是每一次都冲进去手动 rm，而是把检查机制前置，让系统在空间恶化到影响业务之前就发出信号。下面这三项配置花不了多少时间，但能避免大多数的深夜故障电话。

### cron 定时检查磁盘阈值

靠人盯着磁盘使用率不现实，最简单的自动化方案是写一个 shell 脚本扔进 crontab，比如每 10 分钟跑一次，用 `df -hP` 提取使用率，超过 85% 就发报警。实践中我们通常不会只取 85% 一条线，而是分两级：80% 发提醒，90% 发严重告警并自动触发清理动作。报警渠道可以直接调用企业微信/钉钉 webhook，或者发邮件，但邮件有个问题——磁盘满了会导致本机邮件队列堆积，反而加剧 inode 耗尽。因此更稳妥的做法是把监控数据推到外部，比如写到云厂商的监控接口，或由 Prometheus Node Exporter 收集后统一告警。对于没有现成监控体系的小团队，这条 cron 报警就是最后一道防线。

### 设置日志自动轮转策略

手动删日志治标不治本，真正让磁盘稳定的是日志轮转。标准的做法是检查 `/etc/logrotate.conf` 和 `/etc/logrotate.d/` 下有没有覆盖到所有会写日志的服务——不仅是 nginx、MySQL，还包括你自己写的应用。参数上要设定 `size` 或 `daily` 触发条件，`rotate` 保留份数，以及 `compress` 压缩旧日志，否则几十个几百兆的日志文件照样吃满空间。容易被忽略的是容器日志：Docker 的 json-file 驱动默认不限制大小，需要在 daemon.json 里加 `"log-opts":{"max-size":"10m","max-file":"3"}`，或者切到 journald、awslogs 这类驱动。容器环境下，光配 logrotate 是不够的，必须把容器日志也纳入治理范围，否则几个月后 `/var/lib/docker` 又会撑爆。

生产环境中遇到 Linux 磁盘空间爆满，往往是运维深夜报警的源头。处理这类问题，关键不是盲目 rm -rf，而是用 df、du 配合查找命令快速定位并安全清理。本文不罗列命令，只还原一套实战中验证过的排查路径：先从分区整体占用率开始，再逐步拆解到目录和文件，最后处置那些“已删却未释放”的隐形占用。

腾讯云国际站：Linux 磁盘空间爆满怎么办？df、du 命令与日志清理实战

生产环境中遇到 Linux 磁盘空间爆满，往往是运维深夜报警的源头。处理这类问题，关键不是盲目 rm -rf，而是用 df、du 配合查找命令快速定位并安全清理。

运维

操作系统

后端

Linux磁盘空间爆满时，如何快速定位并安全清理？本文提供实战指南：先用df检查分区使用率，再用du逐层排查大文件，结合lsof处理"已删未释放"文件。重点讲解日志清理技巧（journalctl、logrotate）、临时文件处理及Docker空间优化，并分享预防性监控方案。掌握这些方法可有效避免磁盘爆满导致的业务中断。

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Linux磁盘空间爆满时，如何快速定位并安全清理？本文提供实战指南：先用df检查分区使用率，再用du逐层排查大文件，结合lsof处理"已删未释放"文件。重点讲解日志清理技巧（journalctl、logrotate）、临时文件处理及Docker空间优化，并分享预防性监控方案。掌握这些方法可有效避免磁盘爆满导致的业务中断...

腾讯云国际站：Linux 磁盘空间爆满怎么办？df、du 命令与日志清理实战-腾讯云开发者社区-腾讯云

腾讯云国际站：Linux 磁盘空间爆满怎么办？df、du 命令与日志清理实战

腾讯云国际站：Linux 磁盘空间爆满怎么办？df、du 命令与日志清理实战

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐