Linux 服务器磁盘空间不足？从排查到自动清理的完整方案

文章摘要： Linux 服务器运行一段时间后，经常会遇到磁盘空间不足的问题。日志文件持续增长、Docker 镜像占用空间、临时文件堆积，都可能导致磁盘使用率达到 100%，进而引发网站无法访问、数据库异常等问题。本文介绍 Linux 磁盘空间排查、日志清理、Docker 空间回收以及自动化监控的实用方法。

SEO关键词： Linux服务器磁盘清理、Linux磁盘空间不足、服务器运维、磁盘使用率排查、Docker磁盘清理、Linux日志清理

一、检查服务器磁盘使用情况

当服务器出现磁盘空间不足时，不要直接删除文件，首先需要确定是哪个分区占用了大量空间。

执行以下命令：

df -h

输出示例：

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        50G   47G  3.0G  95% /
/dev/vdb1       100G   20G   80G  20% /data

从结果可以看到，根分区使用率已经达到 95%，而数据分区仍有较多剩余空间。

接下来，使用 du 查找占用空间较大的目录：

du -xhd1 / 2>/dev/null | sort -hr

其中：

• -x：仅统计当前文件系统，避免跨分区统计。
• -h：以易读的单位显示容量。
• -d1：只统计当前目录的下一层。
• sort -hr：按照容量从大到小排序。

如果发现 /var 目录占用较大，可以继续检查：

du -xhd1 /var 2>/dev/null | sort -hr

通过逐层排查，通常能够定位到日志目录、Docker 数据目录或应用上传目录。

二、清理 Linux 系统日志

系统日志是服务器磁盘空间增长的常见来源之一。

先检查日志目录：

du -sh /var/log

查看占用空间较大的日志文件：

find /var/log -type f -size +100M -exec ls -lh {} \;

如果发现某个日志文件异常增长，例如 app.log，不要直接删除正在使用的文件。可以先确认对应服务是否仍在写入，然后通过日志轮转或截断文件的方式处理。

例如：

truncate -s 0 /var/log/app.log

注意： 执行前必须确认该文件确实可以清空，并评估日志是否需要保留用于故障追踪或审计。不要将上述命令直接用于整个日志目录。

如果服务器使用 systemd，可以查看 journal 日志占用：

journalctl --disk-usage

例如，将系统日志限制在最近 7 天：

journalctl --vacuum-time=7d

也可以按照容量限制清理：

journalctl --vacuum-size=1G

这两种命令都会删除部分历史日志。生产环境应根据日志留存要求选择合适的策略。

三、清理 Docker 占用的磁盘空间

如果服务器部署了 Docker，镜像、停止的容器、构建缓存和未使用的数据卷都可能占用大量磁盘空间。

首先查看 Docker 磁盘使用情况：

docker system df

查看更详细的统计信息：

docker system df -v

清理未使用的镜像、停止的容器和构建缓存，可以执行：

docker system prune

执行前，Docker 会提示确认清理范围。

如果还需要清理未使用的镜像，可以使用：

docker system prune -a

该命令可能删除不再被容器引用的镜像，后续重新部署时可能需要重新拉取。

需要特别注意的是，Docker 数据卷可能保存数据库文件、上传图片或其他持久化数据。不要在没有核实的情况下执行：

docker system prune --volumes

清理之前，应确认数据是否有备份，以及是否存在后续需要使用的卷。

四、处理磁盘已满但找不到大文件的问题

有时执行 df -h 会发现磁盘已经接近满载，但通过 du 统计目录时，却找不到对应的占用空间。

一种常见原因是：文件已经被删除，但仍有进程持有该文件的打开句柄。

例如，应用程序持续写入一个大型日志文件。即使删除了该文件，只要进程仍然打开它，文件占用的磁盘空间就不会立即释放。

可以使用以下命令排查：

lsof +L1

如果发现某个服务持有大量已删除文件，可以结合进程信息确认原因，再通过应用自身的日志重开机制或受控重启释放空间。

不要直接终止不明进程。数据库、Web 服务等关键进程需要先评估影响，再制定处理方案。

另一种可能是 inode 耗尽。此时，即使磁盘还有剩余容量，也可能无法创建新文件。

检查 inode 使用率：

df -i

如果 inode 使用率达到 100%，应重点排查大量小文件，例如缓存文件、会话文件或临时文件，而不是只关注大文件。

五、配置磁盘空间自动监控

手动排查只能解决当前问题。对于长期运行的生产服务器，更合理的做法是设置磁盘使用率告警。

下面是一个简单的 Shell 检查脚本：

#!/bin/bash

THRESHOLD=85

df -P / | awk 'NR==2 {
    gsub(/%/, "", $5)
    if ($5 >= 85) {
        printf "WARNING: root filesystem usage is %s%%\n", $5
        exit 1
    }
}'

这个脚本会在根分区使用率达到 85% 时输出告警信息，并返回非零退出状态。

如果希望阈值通过变量统一控制，可以将判断逻辑改为：

#!/bin/bash

THRESHOLD=85

USAGE=$(df -P / | awk 'NR==2 {
    gsub(/%/, "", $5)
    print $5
}')

if [ "$USAGE" -ge "$THRESHOLD" ]; then
    echo "磁盘告警：根分区使用率 ${USAGE}%"
fi

保存为 disk-check.sh 后，赋予执行权限：

chmod +x disk-check.sh

运行测试：

./disk-check.sh

实际生产环境中，可以通过定时任务定期执行，并将告警发送到邮件、企业微信或其他监控系统。需要注意，脚本只有在被定时执行、且告警接入真实通知渠道后，才能形成完整的监控闭环。

六、生产环境的磁盘管理建议

为了减少磁盘空间问题对业务的影响，可以从以下几个方面完善运维策略。

1. 设置磁盘告警阈值。 建议根据业务增长速度，在使用率达到 80%～85% 时提前告警，不要等到磁盘完全写满才处理。
2. 配置日志轮转。 使用 logrotate 限制日志文件大小和保留周期，避免应用日志无限增长。
3. 定期检查 Docker 数据。 区分可删除的缓存和必须保留的持久化数据，不要依赖无差别清理命令。
4. 为关键数据保留备份。 清理前确认文件用途，数据库和业务上传文件应有明确的备份及恢复方案。
5. 监控 inode 使用率。 大量小文件同样可能导致服务异常，应将 inode 纳入监控范围。
6. 建立容量增长趋势分析。 不仅关注当前使用率，还应分析每天的增长量，提前规划扩容时间。

七、总结

Linux 服务器磁盘空间不足，并不意味着必须立即扩容。正确的处理顺序应该是：先使用 df -h 确认分区状态，再通过 du 定位大目录，随后检查日志、Docker 数据以及已删除但仍被占用的文件。

对于生产环境，更重要的是建立长期的磁盘管理机制，包括日志轮转、容量监控、告警通知和定期检查。

运维工作的重点不是每次磁盘满了再去清理，而是让磁盘使用率在达到危险阈值之前就被发现和处理。