Linux磁盘空间告急？三步精准定位空间占用元凶

当服务器突然发出磁盘空间不足的警报，运维人员常常会陷入手忙脚乱的排查过程。盲目删除文件不仅效率低下，还可能误删关键数据。本文将分享一套经过实战检验的三步排查法，结合 du 、 find 和 sort 命令的强大功能，帮助您快速定位磁盘空间占用的真正元凶。

1. 全局扫描：快速锁定问题区域

面对磁盘空间告警，第一步应该是全面了解当前磁盘使用情况。 df -h 命令能直观显示各挂载点的空间使用率：

$ df -h
文件系统        容量  已用  可用 已用% 挂载点
/dev/vda1        50G   48G  1.1G   98% /

当发现根目录接近满载时，使用 du 命令进行初步排查：

$ sudo du -h --max-depth=1 / | sort -hr | head -10
48G     /
23G     /var
15G     /home
5.4G    /usr
1.2G    /opt

关键技巧：

• --max-depth=1 限制只显示一级子目录
• sort -hr 按人类可读格式逆序排序
• head -10 仅显示前10个结果

这个组合能立即揭示空间占用最大的几个目录，为后续深入排查指明方向。在我的实践中，/var目录往往是首要嫌疑对象，特别是日志和数据库文件。

2. 精确制导：深入问题目录排查

锁定问题目录后，需要更精细的分析工具。 ncdu （NCurses Disk Usage）是交互式磁盘分析利器：

$ sudo apt install ncdu  # Debian/Ubuntu
$ sudo yum install ncdu  # CentOS/RHEL
$ ncdu /var

ncdu会生成可视化分析界面，支持：

• 按大小排序文件和目录
• 实时导航文件系统树
• 直接删除不需要的文件

对于没有ncdu的环境，可以用find命令实现类似功能：

$ sudo find /var -type f -exec du -h {} + | sort -hr | head -20
15G     /var/lib/mysql/ibdata1
3.2G    /var/log/apache2/access.log
1.8G    /var/log/nginx/error.log

特别注意：

• 数据库文件(如ibdata1)需要专业维护，不可直接删除
• 日志文件应先清空而非删除（使用 truncate 或 > 操作）

3. 专业处理：安全释放磁盘空间

找到大文件后，需根据文件类型采取不同处理策略：

日志文件处理

对于持续写入的日志文件，推荐使用日志轮转工具：

# 查看当前日志轮转配置
$ ls /etc/logrotate.d/

# 手动执行轮转并清理旧日志
$ sudo logrotate -f /etc/logrotate.d/nginx

数据库维护

MySQL等数据库文件需要专业维护命令：

-- 优化InnoDB表空间
OPTIMIZE TABLE large_table;

-- 清理二进制日志
PURGE BINARY LOGS BEFORE '2023-01-01';

容器清理

Docker环境会产生大量缓存和镜像：

# 清理无用容器、镜像和卷
$ docker system prune -af

# 查看详细磁盘使用
$ docker system df

终极解决方案： 对于特别顽固的空间占用，可考虑以下组合拳：

# 1. 清空日志文件
$ sudo truncate -s 0 /var/log/oversized.log

# 2. 重启相关服务释放文件句柄
$ sudo systemctl restart nginx

# 3. 确认空间已释放
$ df -h

实战案例：一次真实的空间救援

最近处理的一起案例中，某服务器根目录突然爆满。通过上述方法快速定位到是MySQL的临时文件：

$ sudo lsof +L1 | grep deleted
mysql     1234   root   10u   REG    8,1 1073741824     0 /tmp/ibtmp1 (deleted)

解决方案是安全重启MySQL服务并配置合理的临时文件大小：

[mysqld]
tmp_table_size=64M
max_heap_table_size=64M

这套方法不仅解决了当务之急，还通过配置优化预防了问题复发。记住，专业的运维不是简单的"找大文件删删删"，而是建立系统的排查思路和规范的维护流程。