我要评论在日常维护 linux 服务器时，我们经常会遇到这样的场景：系统报错提示“磁盘空间不足”，执行 ls -l 看到一长串数字，或者 df -mh 发现根目录挂载点进度条已经变红（98% 以上）。
今天就以一次真实的排查过程为例，分享如何科学地处理大文件与日志。
一、 识破数字：ls -l 里的 30482163185 到底有多大？
当你执行 ls -l 时，文件大小默认是以 byte（字节） 为单位显示的。对于上百亿的数字，肉眼很难直观判断。
1. 快速换算公式
计算机系统中，单位换算通常遵循 $1024$ 进制：
$$30482163185 \text{ b} \div 1024 \div 1024 \div 1024 \approx 28.39 \text{ gib}$$
也就是说，这个文件占用了约 28.4 gb 的空间。
2. 懒人必备命令
与其手动计算，不如在执行命令时加个 -h 参数（human-readable）：
ls -lh：直接显示为29g。du -sh *：查看当前目录下各个文件/文件夹的总大小。
二、 深度排查：为什么我的根目录（/）满了？
很多时候，我们发现 /opt 或 /var 下有大文件，但并没有意识到它们属于哪个分区。
1. 寻找挂载点逻辑
通过 df -mh 命令可以观察磁盘分布。如果你的输出显示 / 分区大小为 50g，而 /home 分区有 4.5t，那么：
- 如果
/opt没有独立出现在“挂载点”一列，它就物理属于根目录（/）分区。 - 当
/opt下产生一个 28g 的日志时，仅有 50g 的根目录就会迅速告急（使用率直冲 98%）。
2. 空间不平衡的痛
这种“贫富差距”巨大的分区架构（根目录小、home 目录大）在 centos 等系统中很常见。最佳实践是：将数据、日志、大型应用安装在 /home 下，或者在 /home 创建目录并软链接到根目录。
三、 治理长大的 nohup 日志：四种方案
程序运行产生的 1.log 越来越大，直接删掉文件往往无法释放磁盘（因为进程仍持有文件句柄）。我们需要更优雅的处理方式：
方案 a：在线清理（急救）
不需要停止程序，直接清空内容：
# 推荐方式，将文件置为 0 字节 true > 1.log # 或者 cat /dev/null > 1.log
方案 b：重定向至“富裕”分区（治本）
既然 /home 有 4.4t 空间，为何不把日志放过去？
# 启动时指定路径 nohup ./start.sh > /home/logs/1.log 2>&1 &
方案 c：使用 logrotate（自动化）
利用 linux 自带的 logrotate 工具进行日志滚动。创建配置文件 /etc/logrotate.d/myapp：
/opt/app/1.log {
daily
rotate 5
copytruncate # 关键：先复制再清空，适合 nohup 进程
compress
missingok
}方案 d：实时切分（进阶）
利用 rotatelogs 等工具，在产生日志时就按大小或时间切分，避免单个大文件的出现。
四、 总结
- 多用
-h参数：无论是ls -lh还是df -h，直观的数据能帮你更快决策。 - 警惕根目录空间：核心系统分区一旦爆满，可能导致 ssh 无法登录、数据库损坏等严重后果。
- 日志必须治理：任何通过
nohup启动的服务，都必须考虑日志清理或切分策略。
到此这篇关于linux服务器磁盘空间不足的排查与处理方法的文章就介绍到这了,更多相关linux磁盘空间不足内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论