企业官网建设流程全解析

机器用久了，很容易生成很多临时或者无用的文件，占用大量空间造成磁盘不够用。尤其是服务器，当磁盘不够用时，系统会出现莫名其妙的问题，数据库可能会造成数据损坏。此时快速定位可以删除的大文件并及时释放空间，是非常重要的。

目录

第一步、查看磁盘整体使用情况

第二步、查找占用空间大的文件和目录

2.1 查找占用最大的前十个文件或目录

2.2 查看当前目录所有子文件和子目录的大小

2.3 查看包含隐藏文件夹的大小

第三步、系统日志清理

第四步、Docker日志清理

第五步、可能涉及的场景

【参考】

第一步、查看磁盘整体使用情况

这里使用df命令，它可以查看所有已挂载磁盘的使用情况：

> df -h

• -h 把输出中的磁盘空间按照友好形式显示，比如M，G，T等等。

输出类似：

这里着重注意两列：

• Avail，可用空间，直接看那些空间不够用的磁盘
• Mounted on，挂载点，确定了有问题的磁盘后，查看对应的挂载点，一般一个磁盘就是根目录 / 。

第二步、查找占用空间大的文件和目录

这里使用du命令，他可以查看特定目录（默认当前目录）下所有文件、目录和自目录的占用情况。

2.1 查找占用最大的前十个文件或目录

> du -c | sort -nr | head -10

• du -c 显示已列出文件总的大小
• sort -nr 表示按数字大小倒序排列
• head -10 表示显示前10个

输出类似：

可以看出来，示例中最占用空间的是mysql的数据文件，还有一个系统日志文件。这里每个人的情况不一样，也可能会找到别的大文件，确认是否可以腾出空间。接下来讲一下系统日志的清理。

2.2 查看当前目录所有子文件和子目录的大小

> du -sh *

这里层层往下找的时候很好用，找到最大的目录，然后查看它下面的占用分布，然后再找到其中最大的，一层层递进很容易找到问题点。

输入类似：

可以看到/var/log占用了4.1G，此时可以 cd 到此目录然后继续运行此命令，直到找到问题所在。

2.3 查看包含隐藏文件夹的大小

有些隐藏文件夹会很大，比如缓存文件等。

> du -sh .[!.]* * | sort -h # 或 > du -sh .[^.]* .??* * | sort -h

能看到诸如 .cache、.npm、.vnc、.bash_history、.local/share/Trash 等隐藏目录/文件，它们往往把空间吃掉了。

> du -ah --max-depth=1 /root | sort -hr | head

把 /root 下所有条目（含隐藏）按大小排序，一眼就能定位到“元凶”。

第三步、系统日志清理

在linux系统中，journal和syslog都是比较基础的日志服务，很多时候会发现journal日志变得越来越大，可以通过配置来释放空间。

查看配置：

> journalctl --disk-usage

发现占用了4G，我们配置成500M：

> journalctl --vacuum-size=0.5G

可以看到，配置大小后，相关日志马上被清理了。

还可以配置日志存储的期限：

> journalctl --vacuum-time=1months

需要注意的一点是，因为缩短了保存时间和减小了空间大小，建议定期做好系统的备份。

第四步、Docker日志清理

如果有安装docker，注意有些应用可能造成日志爆盘。

4.1、先用df -h查看整体使用

df -h

可以看到/var/lib/docker是元凶（overlay2 目录已经撑满）。

4.2、查看日志情况

du -h /var/lib/docker/containers/*/*-json.log 2>/dev/null | sort -rh | head

可以看到第一个容器占用的日志有46G，可以判断这是对应容器出了问题。

4.3、查找容器

通过上面输出日志路径：

/var/lib/docker/containers/a4318930029c386725e97f2f9b36d6d856f527cf9093932ce5a39169e28547fc/a4318930029c386725e97f2f9b36d6d856f527cf9093932ce5a39169e28547fc-json.log

取前12位即为容器ID：a4318930029c

4.4、查看最新日志输出

docker logs --tail 100 a4318930029c

可以看到该容器试图访问nacos，结果没有成功，然后反复重启，反复报错。

也可以用下面命令统计重复的日志输出：

# 取最后 1 万行，统计出现最多的内容 # tail -n 10000 <日志文件路径> | awk -F'"log":"' '{print $2}' | sort | uniq -c | sort -rn | head -20 tail -n 10000 /var/lib/docker/containers/a4318930029c386725e97f2f9b36d6d856f527cf9093932ce5a39169e28547fc/a4318930029c386725e97f2f9b36d6d856f527cf9093932ce5a39169e28547fc-json.log | awk -F'"log":"' '{print $2}' | sort | uniq -c | sort -rn | head -20

这会告诉你“哪条日志被刷了最多遍”，基本就能锁定罪魁祸首。

找到问题原因后，接下来就是从应用层面修复问题，比如这里修复nacos的问题。

4.5、清空日志

修复容器内应用的问题后，就可以清空该日志文件（不要rm，rm后 Docker 仍持有文件句柄，空间不会释放）：

truncate -s 0 /var/lib/docker/containers/a4318930029c386725e97f2f9b36d6d856f527cf9093932ce5a39169e28547fc/a4318930029c386725e97f2f9b36d6d856f527cf9093932ce5a39169e28547fc-json.log

4.6、配置docker限制日志输出

为了避免docker内部署应用不可预料的行为，建议从docker级别来限制日志输出。

4.6.1、全局配置

编辑/etc/docker/daemon.json（没有就新建）：

{ "log-driver": "json-file", "log-opts": { "max-size": "100m", "max-file": "3" } }

含义：每个容器日志最大 100M，最多保留 3 个文件（滚动），单个容器最多占 300M。

然后重启 Docker（会重启所有容器，注意业务影响）。

daemon.json 的日志配置只对新创建的容器生效。

4.6.2、单应用配置

docker run --log-opt max-size=100m --log-opt max-file=3 ...

或在docker-compose.yml中：

services: your-service: logging: driver: json-file options: max-size: "100m" max-file: "3"

这些配置也是只有在创建时配置才生效。

第五步、可能涉及的场景

5.1、访问网页提示 net::ERR_INCOMPLETE_CHUNKED_ENCODING 200 (OK)

在chrome中使用开发者工具，发现错误：

GET https://www.demo.com/static/js/echarts.dbf449d8.jsnet::ERR_INCOMPLETE_CHUNKED_ENCODING 200 (OK)

这个错误表示 Nginx 在向浏览器传输文件（这里是echarts.js）时，数据没有完整发送就被意外中断了。

这个错误通常发生在使用“分块传输编码”（Chunked Transfer Encoding）传输响应时，客户端（浏览器）没有收到结束标志，或者收到的数据不完整。

Nginx 在磁盘满的状态下，reload、写临时文件、缓存管理都可能表现异常。

【参考】

Linux环境下通过journal命令查看和管理日志_linux journal-CSDN博客

centos7下解决journal日志越来越大的问题-腾讯云开发者社区-腾讯云