背景与问题

磁盘空间耗尽是服务器运维中最常见的问题之一。当磁盘写满后，应用无法写入日志、无法创建新文件、无法写入数据、数据库无法完成刷盘、SSH 可能无法建立新连接。表现为：写入文件报 "No space left on device"、日志停止写入、服务开始报无法连接、SSH 登录后无法执行命令。

磁盘满的问题排查难度在于：空间被谁占用是不直观的，特别是当日志文件被删除但进程仍持有文件描述符时。清理磁盘空间也不是简单地删除文件，需要理解哪些文件可以删、哪些正在被使用、删除后影响是什么。

本文以 RHEL 9、AlmaLinux 9、Ubuntu 22.04 LTS 为测试环境，系统讲解 Linux 磁盘管理机制、空间占用分析方法、常见占用来源、清理策略、以及预防措施。涵盖文件系统和 LVM 两个维度，覆盖日志文件、数据库文件、临时文件、缓存文件等常见场景。

1. 磁盘空间基础概念

1.1 磁盘空间相关概念

Linux 中与磁盘空间相关的几个关键概念：

文件系统空间（Filesystem level）：文件系统层面的可用空间，通过 df 命令查看。这是应用能直接使用的空间。

逻辑卷空间（ LVM level ）：如果使用 LVM 管理磁盘，逻辑卷的空间可能小于物理卷，或者逻辑卷已经扩展但文件系统未扩展。

物理磁盘空间（Physical disk level）：硬盘分区的实际大小，与分区表和 RAID 配置相关。

inode 数量：文件系统不仅限制空间使用，还限制 inode 数量。inode 是存储文件元数据的结构，inode 耗尽时即使有空间也无法创建新文件。

block 大小：文件系统的最小分配单元，通常是 4KB。写入 1 字节的文件也会占用 4KB 空间，这是小文件多时磁盘占用虚高的原因之一。

1.2 查看磁盘空间状态

# 查看所有文件系统的空间使用情况df -h# 查看 inode 使用情况df -i# 以 inode 和空间占用排序df -idf -h# 查看特定目录的磁盘使用（逐层深入）du -sh /var/*du -h --max-depth=1 /var# 找出大文件find / -type f -size +100M -exec ls -lh {} \;

1.3 理解 df -h 输出

$ df -hFilesystem      Size  Used Avail Use% Mounted ontmpfs           3.9G     0  3.9G   0% /dev/shm/dev/sda1       100G   45G   55G  45% //dev/mapper/vg-root  200G   180G   20G  90% /data

• Size：文件系统总大小
• Used：已使用空间
• Avail：可用空间
• **Use%**：使用率
• Mounted on：挂载点

当 Use% 达到 90% 以上时应该引起警惕，达到 95% 以上时必须立即处理。Avail 显示的可用空间是 root 和普通用户的可用空间之和，对所有用户一致。

2. 快速定位占用来源

2.1 分层排查法

磁盘空间占用的排查应该分层进行，从大到小逐步定位：

# 第一层：确定哪个挂载点满了df -h# 第二层：确定哪个目录占用最多du -sh /*du -h --max-depth=1 / | sort -hr | head -10# 第三层：进入占用最多的目录继续排查du -h --max-depth=1 /vardu -h --max-depth=1 /var/log

2.2 快速定位大文件

当磁盘使用率达到 95% 以上时，需要快速找到可以清理的大文件：

# 查找大于 500MB 的文件find / -type f -size +500M -exec ls -lh {} \; 2>/dev/null# 查找特定目录下大于 100MB 的文件find /var -type f -size +100M -exec ls -lh {} \; 2>/dev/null# 按大小排序查看目录内容du -ah /var | sort -rh | head -20# 只看文件不看目录du -ah /var | grep -v '/$' | sort -rh | head -20

2.3 查找被删除但仍被进程占用的文件

这是最容易被忽视的问题：文件被删除但进程仍持有文件描述符，导致空间无法释放：

# 方法一：查看已删除但未释放的空间lsof +L1# 方法二：查看所有打开文件的进程lsof | grep deleted# 方法三：查看特定进程的打开文件ps aux | grep process_namels -la /proc/PID/fd | grep deleted

为什么会这样：当进程打开一个文件时，内核会为该文件分配一个文件描述符。即使在文件系统层面删除了文件，只要进程仍持有该文件描述符，文件占用的空间就不会被释放。这种情况在日志文件被 logrotate 切割后常见：logrotate 移动了日志文件，但 Nginx 或应用程序仍然写入到旧的 FD。

解决方法：重启持有文件描述符的进程；或者向进程发送 SIGUSR1（对于支持重新打开日志的进程如 Nginx）或 SIGHUP 信号。

# 对于 Nginx，重新打开日志nginx -s reopen# 或者向 master 进程发送信号kill -USR1 $(cat /var/run/nginx.pid)# 查看哪些文件描述符被标记为 deleted 但仍被占用lsof +L1 | grep -v "memfd"

3. 日志文件排查与清理

3.1 日志文件空间占用分析

日志是磁盘空间消耗的大户。排查日志占用：

# 查看 /var/log 目录总大小du -sh /var/log# 查看 /var/log 下各子目录的大小du -h /var/log | sort -rh | head -20# 查看具体的日志文件大小ls -lhS /var/log/*.log# 统计各日志文件的行数wc -l /var/log/*.log

3.2 常见日志文件说明

Linux 系统和常用服务的日志文件：

3.3 安全清理日志文件

清理日志文件时，不能直接用 rm 删除正在写入的文件，否则会导致进程继续占用已删除文件的空间（如前所述）。正确做法：

对于支持信号刷新日志的进程：

# Nginx：通知重新打开日志文件nginx -s reopen# 或者发送信号kill -USR1 $(cat /var/run/nginx.pid)# 然后删除旧日志文件rm /var/log/nginx/access.log.1

对于不支持的进程，使用 truncate 命令清空文件内容而不删除文件：

# 清空文件内容但保留文件描述符truncate -s 0 /var/log/nginx/access.log# 或者使用 : > 语法: > /var/log/nginx/access.log

对于可以安全删除的文件（如已切割的旧日志）：

# 删除旧的日志文件rm /var/log/nginx/access.log.2026-04-*.gz# 删除 7 天前的日志find /var/log -name "*.gz" -mtime +7 -delete# 删除 30 天前的日志find /var/log -name "*.log.*" -mtime +30 -delete

3.4 日志切割配置检查

检查 logrotate 配置确保日志被正确切割：

# 查看 logrotate 配置cat /etc/logrotate.confcat /etc/logrotate.d/nginx# 示例配置/var/log/nginx/*.log {    daily    missingok    rotate 14    compress    delaycompress    notifempty    create 0640 nginx nginx    postrotate        [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`    endscript}

关键参数：

• daily/weekly/monthly：切割频率
• rotate N：保留 N 份历史日志
• compress：压缩旧日志
• delaycompress：延迟压缩，保留最近一份不压缩
• notifempty：空文件不切割
• postrotate/endscript：切割后执行的命令，通常是通知进程重新打开日志

手动执行 logrotate 调试：

# 强制执行一次 logrotate（加 -f 强制）logrotate -f /etc/logrotate.conf# 查看 logrotate 状态cat /var/lib/logrotate/status# 测试配置是否正确logrotate -d /etc/logrotate.d/nginx

4. 数据库文件空间管理

4.1 MySQL/MariaDB 空间分析

# 登录 MySQL 查看各数据库大小mysql -e "SELECT table_schema AS 'Database', ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS 'Size (MB)' FROM information_schema.tables GROUP BY table_schema;"# 查看各表的详细大小mysql -e "SELECT table_schema, table_name, ROUND(data_length / 1024 / 1024, 2) AS data_mb, ROUND(index_length / 1024 / 1024, 2) AS index_mb FROM information_schema.tables ORDER BY data_length DESC LIMIT 20;"# 查看 binlog 占用空间mysql -e "SHOW BINARY LOGS;"# 查看 innodb 文件大小ls -lh /var/lib/mysql/*.ibd

4.2 MySQL binlog 清理

MySQL binlog 记录所有数据变更，是复制和恢复的基础，但会占用大量空间：

# 查看当前的 binlog 配置mysql -e "SHOW VARIABLES LIKE 'expire_logs_days';"mysql -e "SHOW VARIABLES LIKE 'max_binlog_size';"# 手动删除 binlog（指定到某个 binlog 文件）mysql -e "PURGE BINARY LOGS TO 'mysql-bin.000123';"# 删除某个时间之前的 binlogmysql -e "PURGE BINARY LOGS BEFORE '2026-04-01 00:00:00';"

重要：删除 binlog 前必须确认从库已经接收完毕，否则会导致复制中断。如果使用的是主从复制，应该在主库执行。

设置自动清理：

# 在 my.cnf 中设置expire_logs_days = 7max_binlog_size = 100M

4.3 PostgreSQL 空间分析

# 查看各数据库大小psql -c "SELECT pg_database.datname, pg_size_pretty(pg_database_size(pg_database.datname)) FROM pg_database ORDER BY pg_database_size(pg_database.datname) DESC;"# 查看各表大小psql -c "SELECT schemaname, tablename, pg_size_pretty(pg_total_relation_size(schemaname||'.'||tablename)) FROM pg_catalog.pg_statio_user_tables ORDER BY pg_total_relation_size(schemaname||'.'||tablename) DESC LIMIT 20;"# 查看 WAL 文件占用ls -lh $PGDATA/pg_wal/du -sh $PGDATA/pg_wal/

4.4 PostgreSQL WAL 清理

PostgreSQL 的 WAL（Write-Ahead Log）文件是数据恢复的关键，同样会占用大量空间：

# 检查 wal 保留配置psql -c "SHOW wal_keep_size;"psql -c "SHOW max_wal_size;"# 手动 checkpoint 并清理 WALpsql -c "CHECKPOINT;"# 设置 WAL 保留大小（在 postgresql.conf 中）wal_keep_size = 1GBmax_wal_size = 2GB# 查看归档状态psql -c "SELECT * FROM pg_stat_archiver;"

4.5 MongoDB 空间分析

# 查看数据库列表及大小mongosh --quiet --eval"db.adminCommand('listDatabases')" | grep -E "name|sizeOnDisk"# 查看集合大小mongosh --quiet --eval"db.getCollectionNames().forEach(function(c){ var s=db[c].stats(); print(c + ': ' + (s.size/1024/1024).toFixed(2) + ' MB'); });"# 查看 oplog 大小mongosh --quiet --eval"db.oplog.rs.stats().maxSize / 1024 / 1024"

5. 临时文件和缓存清理

5.1 /tmp 目录清理

Linux 系统重启时 /tmp 通常会被清空，但长时间运行的服务器上 /tmp 可能积累大量文件：

# 查看 /tmp 大小du -sh /tmp# 查看 /tmp 中最占用空间的文件和目录find /tmp -type f -exec ls -lh {} \; | sort -k5 -rh | head -20# 查找过于老旧的文件（30 天未访问）find /tmp -atime +30 -type f -ls# 查找临时文件（按大小排序）find /tmp -type f -printf"%s %p\n" | sort -rn | head -20

5.2 系统缓存清理

Linux 会使用空闲内存做文件缓存，这些内存在需要时会被释放。不应该直接清理 pagecache，但可以 sync 确保数据落盘后手动 drop cache：

# 查看内存和缓存使用free -h# 同步文件系统确保数据落盘sync# 谨慎操作：手动释放 pagecacheecho 3 > /proc/sys/vm/drop_caches

警告：在生产环境中执行 drop_caches 可能导致性能抖动，通常只在排查问题时使用。

5.3 Yarn/NPM/Maven 等包管理器缓存

开发环境和构建服务器上，包管理器缓存可能占用大量空间：

# Yarn 缓存yarn cache diryarn cache clean# NPM 缓存npm cache lsnpm cache clean --force# Maven 缓存du -sh ~/.m2/repositoryrm -rf ~/.m2/repository/*# PIP 缓存du -sh ~/.cache/piprm -rf ~/.cache/pip

5.4 Docker 资源清理

Docker 存储占用往往是最大的磁盘杀手之一：

# 查看 Docker 磁盘使用docker system df# 详细分析各类资源docker system df -v# 清理未使用的资源docker system prune -a        # 删除所有未使用的镜像、容器、网络docker container prune       # 删除已停止的容器docker image prune -a         # 删除未使用的镜像docker volume prune           # 删除未使用的卷docker network prune          # 删除未使用的网络# 清理特定时间之前的资源docker system prune --filter "until=168h"# 删除 7 天前的资源

5.5 旧内核和已卸载包清理

系统更新后旧内核会保留，可能占用数百 MB：

# 查看已安装的内核dpkg --list | grep linux-imagerpm -qa | grep kernel# Ubuntu/Debian 清理旧内核apt-get autoremove -y# 或者使用 purge-old-kernels（如果安装了 byobu）purge-old-kernels --keep 2# RHEL/CentOS 清理旧内核dnf remove $(dnf repoquery --installonly --latest-limit=-2 -q)# 或者package-cleanup --oldkernels --count=2

6. inode 耗尽问题

6.1 inode 概念

inode 是文件系统中存储文件元数据的结构，每个文件对应一个 inode。inode 耗尽时，即使磁盘有空间也无法创建新文件。

# 查看 inode 使用情况df -i# 查看特定文件系统的 inode 数量df -i /# 查看 inode 使用最多的目录find / -xdev -printf'%h\n' | sort | uniq -c | sort -rn | head -10

6.2 大量小文件导致 inode 耗尽

常见原因：邮件队列（/var/spool/mail/）、缓存文件、Nginx 访问日志被切割成大量小文件。

# 统计目录下文件数量find /var/spool -type f | wc -l# 查看某个目录的文件数量分布for dir in /var/*; doecho -n "$dir: "; ls -1A "$dir" 2>/dev/null | wc -l; done# 查找 inode 占用最高的目录find / -xdev -type d -exec sh -c 'echo "$(ls -1A "$1" 2>/dev/null | wc -l) $1"' _ {} \; | sort -rn | head -10

6.3 解决 inode 耗尽

如果是邮件队列导致的：

# 查看邮件队列大小ls -lh /var/spool/mail/# 清理旧邮件（需要确认）find /var/spool/mail -type f -name "*" -mtime +30 -delete

创建文件系统时可以指定 inode 密度：

# 创建时指定mkfs.ext4 -i 8192 /dev/sdb1  # 每 8KB 一个 inode

7. LVM 环境下的问题

7.1 LVM 概念回顾

LVM（Logical Volume Manager）将物理磁盘抽象为卷组（VG）和逻辑卷（LV），提供更灵活的空间管理：

• PV（Physical Volume）：物理卷，对应分区或整个磁盘
• VG（Volume Group）：卷组，多个 PV 组成
• LV（Logical Volume）：逻辑卷，从 VG 中划分

7.2 LVM 空间问题排查

# 查看卷组空间使用vgdisplay# 查看逻辑卷信息lvdisplay# 查看每个 LV 的空间使用lvs -o lv_name,lv_size,data_percent,metadata_percent# 查看 PV 使用情况pvspvdisplay

7.3 扩展逻辑卷

当文件系统空间不足但 VG 有剩余空间时：

# 扩展逻辑卷lvextend -L +10G /dev/mapper/vg-root# 扩展文件系统（ext4）resize2fs /dev/mapper/vg-root# 扩展文件系统（xfs）xfs_growfs /data

7.4 扩展卷组

当 VG 本身空间不足时，需要添加新物理卷：

# 创建新分区或磁盘# 创建物理卷pvcreate /dev/sdb1# 将新 PV 加入 VGvgextend vg_name /dev/sdb1# 扩展 LVlvextend -L +50G /dev/mapper/vg-root# 扩展文件系统resize2fs /dev/mapper/vg-root

7.5 缩小逻辑卷（谨慎操作）

缩小逻辑卷需要先卸载文件系统，风险极高，不推荐在生产环境操作。如果必须操作：

# 卸载文件系统umount /data# 检查文件系统e2fsck -f /dev/mapper/vg-data# 缩小文件系统resize2fs /dev/mapper/vg-data 50G# 缩小 LVlvreduce -L 50G /dev/mapper/vg-data# 重新挂载mount /dev/mapper/vg-data /data

8. 分区表和文件系统修复

8.1 检查文件系统错误

在清理磁盘前，应该检查文件系统是否有错误：

# 检查文件系统（必须先卸载）umount /datae2fsck -f /dev/mapper/vg-data# 检查并修复（自动修复模式）e2fsck -p /dev/mapper/vg-data

注意：不要在已挂载的文件系统上运行 e2fsck（除非使用只读模式）。生产环境应该使用 fsck -n 预览问题。

8.2 修复损坏的 inode

如果 inode 表损坏导致空间统计不准：

# 显示 inode 使用情况dumpe2fs /dev/sda1 | grep -E "Inode size|Inode count|Inode blocks per group|Inodes per group"# 检查损坏的 inodebadblocks /dev/sda1

8.3 修复 LVM 配置损坏

如果 LVM 配置损坏导致无法访问数据：

# 扫描物理卷pvscan# 激活所有卷组vgchange -ay# 查看 LVM 状态lvs -a

9. 紧急处理流程

当磁盘已满导致服务不可用时，按以下顺序处理：

第一步：登录服务器

如果 SSH 已经无法登录，尝试：

# 使用密钥登录ssh -i ~/.ssh/id_rsa user@server# 如果是 SSH 会话仍然活跃但无法执行命令# 尝试执行简单命令df -h /# 如果是根目录满，需要先清理ls -la /tmp

第二步：定位最紧急的占用

# 查看磁盘使用情况df -h# 查找大文件find / -xdev -type f -size +100M -exec ls -lh {} \; 2>/dev/null# 查看已删除但未释放的文件lsof +L1

第三步：立即清理

# 清理临时文件rm -rf /tmp/*rm -rf /var/tmp/*# 清理旧日志（如果进程支持）: > /var/log/messages: > /var/log/secure# 清理包管理器缓存yum clean allapt-get clean all# 清理 Docker（谨慎）docker system prune -f

第四步：通知相关服务

清理完成后，应该通知相关人员日志被清空，并重启相关服务确保日志正常写入：

# 重启日志服务systemctl restart rsyslogsystemctl restart systemd-journald# 重启应用（如果需要）systemctl restart nginxsystemctl restart myapp

10. 预防措施

10.1 磁盘空间监控告警

部署监控是预防磁盘满的最有效手段：

# Prometheus 告警规则示例groups:- name: disk  rules:  - alert: DiskSpaceUsageHigh    expr: (node_filesystem_size_bytes{mountpoint="/"} - node_filesystem_avail_bytes{mountpoint="/"}) / node_filesystem_size_bytes{mountpoint="/"} * 100 > 85for: 5m    labels:      severity: warning    annotations:      summary: "Disk space usage is above 85%"  - alert: DiskSpaceUsageCritical    expr: (node_filesystem_size_bytes{mountpoint="/"} - node_filesystem_avail_bytes{mountpoint="/"}) / node_filesystem_size_bytes{mountpoint="/"} * 100 > 95for: 1m    labels:      severity: critical    annotations:      summary: "Disk space usage is above 95%, immediate action required"

Zabbix 监控模板也推荐部署 LLD（Low Level Discovery）自动发现挂载点并监控。

10.2 日志空间限制

通过配置限制日志目录的最大空间：

# 使用 logrotate 自动管理# 确保配置文件存在且正确# 对于 Nginx，可以限制 access_log 缓冲access_log /var/log/nginx/access.log combined buffer=32k flush=5s;

10.3 独立分区策略

关键目录使用独立分区，防止单一目录占满根分区：

• /var/log 独立分区
• /tmp 独立分区（使用 tmpfs 可以获得更好性能）
• /home 独立分区
• /data 或 /opt 独立分区

# /etc/fstab 示例tmpfs /tmp tmpfs defaults,noexec,nosuid,size=2G 0 0tmpfs /var/tmp tmpfs defaults,noexec,nosuid,size=1G 0 0

10.4 数据库数据目录独立

数据库数据目录应该放在独立分区或 LVM：

# 创建独立 LV 给 MySQLlvcreate -L 100G -n mysql vgmkfs.xfs /dev/mapper/vg-mysqlmount /dev/mapper/vg-mysql /var/lib/mysql

10.5 定期检查脚本

部署定时任务定期检查磁盘空间：

# /etc/cron.daily/disk-check#!/bin/bashTHRESHOLD=85df -h | grep -vE '^Filesystem|tmpfs|cdrom' | awk -v threshold=$THRESHOLD'{if ($5+0 >= threshold) print $1 " " $5 " is above threshold"}' | mail -s "[Alert] Disk space warning" admin@example.com

11. 常见场景处理

场景一：/var/log 目录占满

# 查看 /var/log 各文件大小du -sh /var/log/*ls -lhS /var/log/*.log# 如果是 messages 文件过大: > /var/log/messages# 然后重启 rsyslogsystemctl restart rsyslog# 如果是 secure 文件过大（SSH 暴力破解）: > /var/log/secure# 清理已切割的旧日志find /var/log -name "*.gz" -mtime +7 -deletefind /var/log -name "*.log.*" -mtime +7 -delete

场景二：/ 分区满但 /home 有空间

# 查看根分区占用分布du -h --max-depth=1 / | sort -hr# 常见可疑目录du -sh /var/*du -sh /tmpdu -sh /.snapshots  # Snapper 快照# 如果 /var/lib/docker 占用过大，清理 Dockerdocker system prune -af

场景三：LVM VG 没有剩余空间

# 查看 VG 状态vgdisplay vg_name | grep -E "Free PE|Total PE"# 如果有未使用的 PV，可以移除释放空间vgreduce vg_name /dev/sdc1# 或者扩展 VG（添加新磁盘）pvcreate /dev/sddvgextend vg_name /dev/sdd# 或者缩小某个不常用的 LV# 先备份/卸载umount /mnt/backupe2fsck -f /dev/mapper/vg-backupresize2fs /dev/mapper/vg-backup 50Glvreduce -L 50G /dev/mapper/vg-backup

场景四：Nginx 写入失败但日志文件被删除

# 检查是否有进程持有已删除文件的 FDlsof +L1# 如果是 Nginxnginx -s reopen# 查看 Nginx 错误日志tail -f /var/log/nginx/error.log# 如果 Nginx 仍无法写入，可能是权限问题ls -la /var/log/nginx/chown nginx:nginx /var/log/nginx/

12. 总结

磁盘空间问题排查的核心是分层定位：从 df 确定哪个挂载点，到 du 确定哪个目录，再 find 确定具体文件。

最容易被忽视的问题是已删除但仍被进程占用的文件，用 lsof +L1 可以快速定位。

清理磁盘空间时，必须区分可以立即删除的文件（如旧日志、临时文件）和需要先处理的文件（如正在写入的日志）。对正在写入的文件使用 truncate 清空内容而不是 rm 删除。

LVM 环境下的空间调整比普通分区更灵活，可以在线扩展。生产环境推荐使用 LVM 管理磁盘。

预防比排查更重要：完善的监控告警可以提前发现空间紧张，定期的清理任务可以防止空间耗尽。