Linux磁盘空间满了怎么办，磁盘清理
原文链接：https://mp.weixin.qq.com/s/YWhfnhUTbZ2HctGg87UtYA
一、概述
1.1 背景介绍
磁盘空间问题是Linux服务器运维中最常见的问题之一，没有之一。根据我这些年的统计，在所有生产环境告警中，磁盘相关的告警占比大概在15%-20%左右。而且这类问题往往来得很突然——前一天还好好的，第二天早上磁盘就满了。
为什么磁盘问题这么常见？原因很简单：
- 日志文件在不停地写入
- 应用程序可能存在内存泄漏，产生大量core dump
- 临时文件没有及时清理
- Docker镜像和容器数据堆积
- 数据库binlog或WAL日志疯狂增长
更要命的是，磁盘空间不足会引发连锁反应。数据库写不进去数据，应用程序抛异常，缓存服务挂掉，最后整个业务系统瘫痪。我见过太多P0级别的故障，根因追溯下来就是磁盘满了。
1.2 技术特点
磁盘空间排查看似简单，实际上涉及到Linux文件系统的很多底层知识：
存储空间 vs inode数量
这是很多新手容易忽略的点。磁盘空间有两个维度：一个是存储空间（blocks），另一个是inode数量。即使存储空间还有剩余，如果inode用完了，也无法创建新文件。我就遇到过这种情况：df -h显示还有30%的空间，但系统报"No space left on device"。查了半天才发现是inode耗尽了。
已删除但未释放的文件
这是另一个经典坑。用rm删除了一个大文件，但df显示空间没有释放。原因是还有进程在持有这个文件的文件描述符。文件虽然从目录项中删除了，但数据块并没有真正释放。
预留空间机制
ext4文件系统默认会预留5%的空间给root用户。这个设计是为了防止普通用户把磁盘写满后，root用户连登录都登不了。但在某些场景下，这5%的空间也是可以利用的。
1.3 适用场景
这套排查流程适用于以下场景：
- 生产环境收到磁盘使用率告警
- 应用程序报"No space left on device"错误
- 系统响应变慢，怀疑是磁盘IO问题
- 定期巡检发现磁盘使用率偏高
- 需要制定磁盘空间清理策略
1.4 环境要求
本文的命令和配置基于以下环境测试：
操作系统: Ubuntu 22.04 LTS / CentOS 7.9 / Rocky Linux 9
文件系统: ext4 / xfs
内核版本: 5.15+
容器运行时: Docker 24.x / containerd 1.7.x
监控系统: Prometheus 2.47+ / Grafana 10.x
大部分命令在主流Linux发行版上都能正常使用，个别工具可能需要额外安装。
二、详细步骤
2.1 第一步：快速确认磁盘状态
收到告警后，第一件事是登录服务器，用df命令确认磁盘的整体使用情况：
df -h
输出示例：
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 100G 95G 5.0G 95% /
/dev/sdb1 500G 120G 380G 24% /data
tmpfs 7.8G 1.2M 7.8G 1% /run
/dev/sdc1 200G 200G 0 100% /var/log
看到这个输出，问题就很明显了：根分区使用了95%，/var/log分区已经100%满了。
但光看存储空间还不够，还要检查inode的使用情况：
df -i
输出示例：
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 6553600 6553598 2 100% /
/dev/sdb1 32768000 125000 32643000 1% /data
这个输出就更严重了——根分区的inode几乎用完了，只剩2个。这种情况下，即使还有5G的存储空间，也无法创建新文件。
2.2 第二步：定位大文件和目录
确认磁盘状态后，接下来要找出是什么东西占用了这么多空间。这里有几个工具可以用，我按实用程度排序介绍。
2.2.1 du命令（基础款）
du是Linux自带的命令，不需要额外安装。最常用的用法：
# 查看当前目录下各子目录的大小，按大小排序
du -sh /* 2>/dev/null | sort -rh | head -20
输出示例：
45G /var
32G /home
15G /opt
8.5G /usr
2.1G /root
发现/var目录占用最多，继续往下钻：
du -sh /var/* 2>/dev/null | sort -rh | head -10
输出：
38G /var/log
4.2G /var/lib
1.8G /var/cache
再往下：
du -sh /var/log/* 2>/dev/null | sort -rh | head -10
输出：
25G /var/log/nginx
8.5G /var/log/app
3.2G /var/log/syslog
1.1G /var/log/auth.log
找到了！nginx的日志占了25G。
du命令的问题
du命令有个很大的缺点：慢。在大目录下执行du，可能要等几分钟才能出结果。而且它没有交互式界面，每次都要重新敲命令，效率很低。
2.2.2 ncdu（进阶款，强烈推荐）
ncdu是我日常用得最多的磁盘分析工具，全称是NCurses Disk Usage。它有一个交互式的终端界面，可以快速浏览目录结构，支持排序和删除操作。
安装方式：
# Ubuntu/Debian
apt install ncdu
# CentOS/RHEL
yum install ncdu
# Rocky/Alma Linux
dnf install ncdu
使用方法：
# 分析根目录
ncdu /
# 分析指定目录
ncdu /var/log
# 排除某些目录（比如挂载的网络文件系统）
ncdu / --exclude /mnt --exclude /media
执行后会进入一个交互式界面：
ncdu 1.18 ~ Use the arrow keys to navigate, press ? for help
--- /var/log -------------------------------------------------------
25.1 GiB [##########] /nginx
8.5 GiB [### ] /app
3.2 GiB [# ] syslog
1.1 GiB [ ] auth.log
512.0 MiB [ ] /journal
128.0 MiB [ ] kern.log
Total disk usage: 38.4 GiB Apparent size: 38.2 GiB Items: 15234
在这个界面里，你可以用方向键上下移动，按回车进入子目录，按d删除文件或目录（会有确认提示），按q退出。
ncdu还有个很实用的功能：可以先扫描再查看。在生产环境，我一般会先把扫描结果导出到文件，然后慢慢分析：
# 扫描并导出结果
ncdu -o /tmp/ncdu-root.json /
# 后续直接加载结果，秒开
ncdu -f /tmp/ncdu-root.json
2.2.3 dust（现代款）
dust是用Rust写的du替代品，速度快，输出美观。它会用树状图直观显示目录大小占比。
安装方式：
# Ubuntu 22.04+
apt install dust
# 其他系统用cargo安装
cargo install du-dust
# 或者下载预编译二进制
wget https://github.com/bootandy/dust/releases/download/v1.0.0/dust-v1.0.0-x86_64-unknown-linux-gnu.tar.gz
tar xzf dust-v1.0.0-x86_64-unknown-linux-gnu.tar.gz
mv dust /usr/local/bin/
使用示例：
dust -d 2 /var
输出：
38G ┌── log │ ████████████ │ 82%
4.2G │ ┌── lib │ ██ │ 9%
1.8G │ ├── cache │ █ │ 4%
2.1G ├─┴ var │ ██ │ 5%
46G ┴ . │████████████████████████████████████████████│ 100%
dust的优点是输出很直观，一眼就能看出哪个目录占比最大。但它不支持交互式操作，所以我一般是用dust快速定位，然后用ncdu深入分析。
2.2.4 三款工具对比总结
| 特性 | du | ncdu | dust |
|---|---|---|---|
| 系统自带 | 是 | 否 | 否 |
| 扫描速度 | 中 | 中 | 快 |
| 交互界面 | 无 | 有 | 无 |
| 可视化 | 无 | 简单 | 树状图 |
| 删除功能 | 无 | 有 | 无 |
| 导出结果 | 无 | 有 | 无 |
| 推荐场景 | 简单查询 | 深度分析 | 快速定位 |
我的使用习惯是：紧急情况用du快速定位，日常巡检用ncdu，给领导汇报用dust（因为图好看）。
2.3 第三步：检查已删除但未释放的文件
这是一个非常容易被忽略的问题。有时候你明明删了很多文件，但df显示空间没变化。这时候就要检查是否有进程还在持有已删除文件的句柄。
用lsof命令查找：
lsof +L1 2>/dev/null | head -20
输出示例：
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME
java 12345 app 25w REG 253,1 21474836480 0 12345 /var/log/app/debug.log (deleted)
nginx 23456 www 12w REG 253,1 5368709120 0 23456 /var/log/nginx/access.log (deleted)
看到了吧，有两个进程还在写已删除的文件。java进程持有一个20G的debug.log，nginx持有一个5G的access.log。这25G的空间虽然文件被删了，但实际并没有释放。
解决方法有两种：
方法一：重启进程（推荐）
# 重启应用
systemctl restart app
# 重载nginx（不需要完全重启）
nginx -s reopen
方法二：清空文件而不是删除
如果不能重启进程，可以用truncate清空文件内容：
# 进程还在运行时，用这种方式清空日志
truncate -s 0 /var/log/app/debug.log
# 或者用这种方式
> /var/log/app/debug.log
# 或者
cat /dev/null > /var/log/app/debug.log
这三种写法效果一样，都是把文件内容清空但保留文件本身。这样进程的文件句柄依然有效，空间立即释放。
方法三：强制释放（黑科技，慎用）
如果实在不能重启进程，还有一个黑科技——通过/proc文件系统直接truncate文件描述符：
# 假设进程PID是12345，文件描述符是25
: > /proc/12345/fd/25
这个方法我只在紧急情况下用过几次。原理是直接操作进程的文件描述符，把对应的文件内容清空。但这种操作有风险，可能导致进程行为异常，所以要谨慎。
2.4 第四步：处理inode耗尽问题
如果df -i显示inode使用率很高，说明系统中存在大量小文件。这种情况通常是以下原因导致的：
- 邮件队列堆积（/var/spool/postfix）
- Session文件堆积（/var/lib/php/sessions）
- 缓存文件碎片化（/tmp, /var/cache）
- 容器层文件碎片（/var/lib/docker）
找出哪个目录的文件数量最多：
# 统计各目录的文件数量
for dir in /*; do
echo -n "$dir: "
find "$dir" -xdev -type f 2>/dev/null | wc -l
done | sort -t: -k2 -rn | head -10
输出示例：
/var: 1523456
/home: 234567
/usr: 123456
/opt: 45678
继续细查/var目录：
for dir in /var/*; do
echo -n "$dir: "
find "$dir" -xdev -type f 2>/dev/null | wc -l
done | sort -t: -k2 -rn | head -10
输出：
/var/spool: 1234567
/var/log: 156789
/var/lib: 89012
找到了，/var/spool目录下有120多万个文件。再往下查：
ls -la /var/spool/postfix/deferred/ | head -20
果然是邮件队列堆积了。清理方法：
# 查看邮件队列状态
postqueue -p
# 清空所有队列
postsuper -d ALL
# 如果是Sendmail
rm -rf /var/spool/mqueue/*
另一个常见的inode杀手是PHP session文件：
# 统计session文件数量
ls /var/lib/php/sessions | wc -l
# 清理过期的session
find /var/lib/php/sessions -type f -mtime +7 -delete
2.5 第五步：释放预留空间（救急用）
ext4文件系统默认预留5%的空间给root用户。对于大容量磁盘，这个比例可能太高了。比如1TB的磁盘，5%就是50GB，这个空间平时用不到有点浪费。
查看当前预留比例：
tune2fs -l /dev/sda1 | grep "Reserved block count"
修改预留比例：
# 将预留空间改为1%
tune2fs -m 1 /dev/sda1
# 或者直接设置预留的块数量
tune2fs -r 100000 /dev/sda1
注意：这个操作可以在文件系统挂载状态下执行，不需要卸载。但建议在业务低峰期操作。
对于XFS文件系统，预留空间的机制不太一样，一般不需要调整。
三、示例代码和配置
3.1 常见磁盘杀手处理
3.1.1 日志文件清理
日志文件是最常见的磁盘空间杀手。在清理之前，先确认哪些日志可以安全删除：
# 查找大于100MB的日志文件
find /var/log -type f -size +100M -exec ls -lh {} \; 2>/dev/null
# 查找超过7天的日志文件
find /var/log -type f -mtime +7 -name "*.log" -exec ls -lh {} \;
# 查找并删除超过30天的压缩日志
find /var/log -type f -mtime +30 -name "*.gz" -delete
对于正在被进程写入的日志，不要直接删除，用truncate清空：
# 清空nginx日志
truncate -s 0 /var/log/nginx/access.log
truncate -s 0 /var/log/nginx/error.log
# 通知nginx重新打开日志文件
nginx -s reopen
对于systemd journal日志：
# 查看journal占用空间
journalctl --disk-usage
# 只保留最近7天的日志
journalctl --vacuum-time=7d
# 只保留最近500MB的日志
journalctl --vacuum-size=500M
3.1.2 Docker镜像和容器清理
Docker是另一个磁盘空间大户。我见过很多服务器，/var/lib/docker目录占用上百GB。
# 查看Docker占用的磁盘空间
docker system df
# 输出示例：
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 45 12 12.5GB 8.2GB (65%)
Containers 28 8 2.3GB 1.8GB (78%)
Local Volumes 15 8 45.6GB 23.4GB (51%)
Build Cache 0 0 0B 0B
清理命令：
# 删除所有停止的容器
docker container prune -f
# 删除所有未使用的镜像
docker image prune -a -f
# 删除所有未使用的volume（危险，可能丢数据）
docker volume prune -f
# 一键清理所有未使用的资源
docker system prune -a -f --volumes
# 删除指定时间之前创建的镜像
docker image prune -a -f --filter "until=720h"
对于Kubernetes环境，还要清理containerd的数据：
# 查看crictl占用空间（containerd）
crictl images
crictl ps -a
# 清理未使用的镜像
crictl rmi --prune
# 清理停止的容器
crictl rm $(crictl ps -a -q --state exited)
3.1.3 临时文件清理
临时目录如果长期不清理，也会堆积大量垃圾：
# 查看/tmp目录大小
du -sh /tmp
# 删除超过7天的临时文件
find /tmp -type f -atime +7 -delete
# 删除超过7天的空目录
find /tmp -type d -empty -mtime +7 -delete
# 清理pip缓存
pip cache purge
rm -rf ~/.cache/pip
# 清理npm缓存
npm cache clean --force
# 清理apt缓存
apt clean
apt autoclean
# 清理yum缓存
yum clean all
rm -rf /var/cache/yum
3.1.4 旧内核清理
升级系统后，旧内核文件会保留在/boot分区。如果/boot分区比较小，很容易被撑满：
# 查看已安装的内核
dpkg --list | grep linux-image # Debian/Ubuntu
rpm -qa | grep kernel # RHEL/CentOS
# 查看当前使用的内核
uname -r
# Ubuntu自动清理旧内核
apt autoremove --purge
# CentOS保留最近2个内核，删除其他
package-cleanup --oldkernels --count=2
3.2 logrotate配置详解
logrotate是Linux下管理日志文件的标准工具。配置得当可以避免90%的日志撑爆磁盘问题。
主配置文件：/etc/logrotate.conf
# 每周轮转一次
weekly
# 保留4份历史日志
rotate 4
# 轮转后创建新的日志文件
create
# 使用日期作为后缀
dateext
# 压缩历史日志
compress
# 延迟压缩，保留最近一份不压缩（便于查看）
delaycompress
# 日志为空时不轮转
notifempty
# 包含其他配置文件
include /etc/logrotate.d
为应用创建专门的轮转配置，以nginx为例：
# /etc/logrotate.d/nginx
/var/log/nginx/*.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 0640 www-data adm
sharedscripts
postrotate
[ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
endscript
}
关键参数解释：
- daily：每天轮转
- rotate 14：保留14份历史
- compress：gzip压缩
- delaycompress：延迟一天再压缩
- missingok：日志不存在也不报错
- notifempty：空文件不轮转
- create 0640 www-data adm：创建新文件的权限和属主
- sharedscripts：多个日志文件共享postrotate脚本
- postrotate/endscript：轮转后执行的命令
按大小轮转（适合增长不规律的日志）：
# /etc/logrotate.d/app
/var/log/app/*.log {
size 100M
rotate 10
compress
missingok
notifempty
copytruncate
}
copytruncate参数很重要：它会先复制日志文件，然后清空原文件。这样即使应用没有处理SIGHUP信号的能力，也能正常轮转。缺点是在复制和清空之间可能丢失几行日志。
手动测试logrotate配置：
# 测试配置是否正确（不实际执行）
logrotate -d /etc/logrotate.d/nginx
# 强制执行轮转
logrotate -f /etc/logrotate.d/nginx
# 查看轮转状态
cat /var/lib/logrotate/status
3.3 tmpwatch/tmpreaper配置
tmpwatch（RHEL系）和tmpreaper（Debian系）用于自动清理临时文件。
CentOS/RHEL安装配置：
# 安装
yum install tmpwatch
# 配置cron任务（/etc/cron.daily/tmpwatch）
/usr/sbin/tmpwatch -umc 720 /tmp
/usr/sbin/tmpwatch -umc 720 /var/tmp
参数说明：
- -u：基于atime（访问时间）判断
- -m：基于mtime（修改时间）判断
- -c：基于ctime（状态改变时间）判断
- 720：小时数（30天）
Ubuntu/Debian安装配置：
# 安装
apt install tmpreaper
# 配置文件：/etc/tmpreaper.conf
TMPREAPER_TIME=7d
TMPREAPER_PROTECT_EXTRA=''
TMPREAPER_DIRS='/tmp/. /var/tmp/.'
TMPREAPER_DELAY='256'
TMPREAPER_ADDITIONALOPTIONS=''
systemd-tmpfiles（现代方案）：
现代Linux发行版更推荐使用systemd-tmpfiles来管理临时文件：
# 查看当前配置
systemd-tmpfiles --cat-config
# 配置文件位置
/etc/tmpfiles.d/ # 管理员自定义配置
/usr/lib/tmpfiles.d/ # 软件包默认配置
/run/tmpfiles.d/ # 运行时配置
创建自定义清理规则：
# /etc/tmpfiles.d/cleanup.conf
# 类型 路径 模式 用户 用户组 生命周期 参数
# 清理超过10天的/tmp文件
d /tmp 1777 root root 10d
# 清理超过30天的/var/tmp文件
d /var/tmp 1777 root root 30d
# 清理超过7天的应用临时文件
D /var/app/tmp 0755 app app 7d
# 每次启动时清空指定目录
D /run/app 0755 app app -
手动执行清理：
# 清理临时文件
systemd-tmpfiles --clean
# 创建目录和文件
systemd-tmpfiles --create
3.4 完整的磁盘清理脚本
下面是我在生产环境使用的一个磁盘清理脚本，包含了常见的清理项目和安全检查：
#!/bin/bash
# disk_cleanup.sh - 生产环境磁盘清理脚本
# Author: SRE Team
# Version: 2.1
# Last Modified: 2025-01-05
set -euo pipefail
# 配置参数
LOG_RETAIN_DAYS=30
TMP_RETAIN_DAYS=7
DOCKER_IMAGE_AGE="720h" # 30天
MIN_FREE_PERCENT=10
DRY_RUN=${DRY_RUN:-false}
# 颜色输出
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m'
log_info() {
echo -e "${GREEN}[INFO]${NC} $(date '+%Y-%m-%d %H:%M:%S') $1"
}
log_warn() {
echo -e "${YELLOW}[WARN]${NC} $(date '+%Y-%m-%d %H:%M:%S') $1"
}
log_error() {
echo -e "${RED}[ERROR]${NC} $(date '+%Y-%m-%d %H:%M:%S') $1"
}
# 获取磁盘使用率
get_disk_usage() {
local mount_point=${1:-/}
df -h "$mount_point" | awk 'NR==2 {gsub(/%/,""); print $5}'
}
# 获取可用空间（GB）
get_free_space() {
local mount_point=${1:-/}
df -BG "$mount_point" | awk 'NR==2 {gsub(/G/,""); print $4}'
}
# 清理前后对比
show_cleanup_result() {
local before=$1
local after=$2
local item=$3
local freed=$((before - after))
if [ $freed -gt 0 ]; then
log_info "$item: 释放了 ${freed}GB 空间"
else
log_info "$item: 无可清理空间"
fi
}
# 清理系统日志
cleanup_system_logs() {
log_info "开始清理系统日志..."
local before=$(get_free_space)
if [ "$DRY_RUN" = "true" ]; then
log_info "[DRY-RUN] 将清理 $LOG_RETAIN_DAYS 天前的日志"
find /var/log -type f -name "*.log" -mtime +$LOG_RETAIN_DAYS 2>/dev/null | head -20
find /var/log -type f -name "*.gz" -mtime +$LOG_RETAIN_DAYS 2>/dev/null | head -20
else
# 清理压缩的旧日志
find /var/log -type f -name "*.gz" -mtime +$LOG_RETAIN_DAYS -delete 2>/dev/null || true
find /var/log -type f -name "*.old" -mtime +$LOG_RETAIN_DAYS -delete 2>/dev/null || true
find /var/log -type f -name "*.[0-9]" -mtime +$LOG_RETAIN_DAYS -delete 2>/dev/null || true
# 清理journal日志
if command -v journalctl &>/dev/null; then
journalctl --vacuum-time=${LOG_RETAIN_DAYS}d 2>/dev/null || true
fi
fi
local after=$(get_free_space)
show_cleanup_result $before $after "系统日志"
}
# 清理临时文件
cleanup_temp_files() {
log_info "开始清理临时文件..."
local before=$(get_free_space)
if [ "$DRY_RUN" = "true" ]; then
log_info "[DRY-RUN] 将清理 $TMP_RETAIN_DAYS 天前的临时文件"
find /tmp -type f -atime +$TMP_RETAIN_DAYS 2>/dev/null | wc -l
find /var/tmp -type f -atime +$TMP_RETAIN_DAYS 2>/dev/null | wc -l
else
find /tmp -type f -atime +$TMP_RETAIN_DAYS -delete 2>/dev/null || true
find /var/tmp -type f -atime +$TMP_RETAIN_DAYS -delete 2>/dev/null || true
find /tmp -type d -empty -delete 2>/dev/null || true
find /var/tmp -type d -empty -delete 2>/dev/null || true
fi
local after=$(get_free_space)
show_cleanup_result $before $after "临时文件"
}
# 清理包管理器缓存
cleanup_package_cache() {
log_info "开始清理包管理器缓存..."
local before=$(get_free_space)
if [ "$DRY_RUN" = "true" ]; then
log_info "[DRY-RUN] 将清理包管理器缓存"
else
# APT (Debian/Ubuntu)
if command -v apt &>/dev/null; then
apt clean 2>/dev/null || true
apt autoclean 2>/dev/null || true
fi
# YUM/DNF (RHEL/CentOS)
if command -v yum &>/dev/null; then
yum clean all 2>/dev/null || true
fi
if command -v dnf &>/dev/null; then
dnf clean all 2>/dev/null || true
fi
fi
local after=$(get_free_space)
show_cleanup_result $before $after "包管理器缓存"
}
# 清理Docker资源
cleanup_docker() {
if ! command -v docker &>/dev/null; then
log_info "Docker未安装，跳过"
return
fi
log_info "开始清理Docker资源..."
local before=$(get_free_space)
if [ "$DRY_RUN" = "true" ]; then
log_info "[DRY-RUN] Docker资源占用情况:"
docker system df
else