过了个双休来到公司，同时发现Linux终端的服务器状态中根目录空间直接爆满100%，周五走之前根目录仅仅使用了59%，同时项目服务的后台不停的有日志打印，而且测试的小伙伴说系统登录不上去了。下面记录一下个人排查并解决这个问题的全过程。 这个服务器部署了两个项目的后台服务，一个是在本机安装了.NET Runtime后部署的.NET Web API以及Dapr应用，另一个是Docker部署的Java项目（微服务），两组后台服务均使用到了消息队列，一组使用到了RabbitMQ，另一组则使用到了RabbitMQ和Kafka。

因为看到后台不停的打印出日志，后台日志服务使用到了Kafka，日志也显示Kafka的一些警告信息。因此我首先想到是不是队列一直消费失败，然后不断尝试、不断报错、不停打印日志写入导致空间爆满。 进入到项目后台的容器编排配置目录，使用 du -sh *查看空间占用，删除了Kafka、ES、RabbitMQ等一些中间件的日志后仅仅腾出了2G空间，服务部署也有俩月了，感觉这个大小属于正常情况，因此根目录爆满可能并非这个原因。

此处排查主要使用du -sh命令，大概介绍参考：

du -ach * #这个能看到当前目录下的所有文件占用磁盘大小和总大小 du -sh #查看当前目录总大小 du -sh * #查看所有子目录大小 du -sh ./* #查看当前目录下所有文件/文件夹的大小 lsof | grep delete #如果怀疑删掉的数据还在占用磁盘空间试试这个 kill -9 pid #结束掉进程就能释放磁盘空间了 du -sh命令介绍

使用du -sh *命令查看根目录下所有子目录的大小

这里需要关注的两个点： （1）为什么出现"du: 无法访问"proc/3514/task/3514/fd/4": 没有那个文件或目录"的输出？（后面再看） （2）哪些目录占用空间巨大？

为什么 /var 目录占用了51个G？本身根目录是/dev/mapper/centos-root的挂载点，因此我怀疑激增的数据就是在var目录中，使用du -sh *命令进行排查

lib目录按照过往的经验一般就是”libraries“，存放一些库、依赖等，但是此处空间大小感觉不太对，上网搜了一下，对linux系统下var/lib的作用是这样描述的：

程序本身执行的过程中，需要使用到的数据文件放置的目录。在此目录下各自的软件应该要有各自的目录。 举例来说，MySQL的数据库放置到/var/lib/mysql/而rpm的数据库则放到/var/lib/rpm去 Linux 系统的/var目录 原创

进入到/var/lib下再次执行du -sh *命令进行排查

发现docker目录空间占用巨大，同时服务器主要用于部署Java服务（使用Docker打包、发布、部署），现在就将主要问题定位到了docker上。

进入到var/lib/docker目录，再次执行du -sh *命令进行排查

为什么docker的overlay2这个目录空间达到32G？到这个环节时基本能够确定是Docker相关的问题了。

通过上面的逐项排查，两天内根目录的空间暴增这个情况基本定位到Docker上。

首先使用Docker内置命令进行Docker空间分布的分析。 docker system df

Docker 的内置 CLI 指令 docker system df ，可用于查询镜像（Images）、容器（Containers）和本地卷（Local Volumes）等空间使用大户的空间占用情况。 Docker 空间使用分析与清理

执行命令得到如下输出：

其中”RECLAIMABLE“表示可回收的 很奇怪的一件事，一共有34个镜像，但是使用的只有24个，是不是说那些没有使用到的镜像就可以删除掉腾出空间了？ 使用docker system df -v 命令查看docker空间占用的详细参数 通过”CONTAINERS“列（此镜像的容器数）发现一些镜像并没有使用到，出现这种未使用的镜像的原因是： （1）项目需求制作服务的基础镜像时形成的冗余镜像，可删除 （2）原本由docker命令部署的容器改为了使用docker-compose部署后之前部署时拉取的重复镜像，可删除 但我觉得这些都不是一个周末后”/“目录从67%到100%爆满的原因。 先清理一下Docker的冗余吧，docker提供了docker system prune空间清理命令

docker system prune 自动清理说明：

Docker 空间使用分析与清理

因为记录之前做了一次清理，当时清理腾出了不到1g的空间。添加-a参数清除所有未使用的镜像和悬空镜像，腾出大约2.49g的空间，但是距离两天前根目录69%的存储还是有一定距离。 此时再使用docker system df命令查看docker的空间分析信息是这样的，似乎镜像于容器本身没什么问题了

再次执行du -sh *命令进行排查

很奇怪的是，其中overlayer2目录仅仅比第一次少了2g，也清理了其它没用的镜像以及日志，那（92%-69%）的23%的根目录空间占用在哪里？？问题很大可能就是overlayer2这个目录了。

Docker目录为： 科普内容就不一一罗列了，Docker的存储目录介绍参考 docker存储目录详解。

然后搜索了关于”docker overlayer2 目录空间暴增“的内容，在下面这篇帖子得到如下答案，Docker Overlay2磁盘空间占用过大清理的方法实现 帖子中第一种情况，对帖子内容进行了概括，大概如下：

情况1： docker中部署的系统中日志内容的不断扩大 。这种情况可以手动、定时进行清理。 对于/var/lib/docker/overlay2 空间占用，存在很多误导的方法是去迁移路径等。 其实磁盘空间的占用和overlay没关系，它的使用和真实的disk使用相同，overlay只是一个docker的虚拟文件系统，真实的文件系统是前者/dev/vda1,可以看到路径所指为根目录。所以，通过该目录去查找哪里占用资源过大。占用大量空间的日志文件位于containers下…

也就是说，containers目录下是以容器id为命名的目录，存放有该容器的一些配置文件以及日志文件

其中日志文件以容器ID-json.log的结构命名，例如8f64f9ed27cc12e5233f877a22a461b7b47d11525cd8069b087333835f9ff802-json.log

在/var/libs/docker/container目录下，通过这个命令查看所有容器的日志文件大小 ls -lh $(find /var/lib/docker/containers/ -name *-json.log) 发现了异常文件！为什么这个容器的日志文件大小是18G？！ 查看这个ID发现是PG数据库 查看容器的日志（最后100条），发现不断再刷新，提示组合键重复，我找到原因了。我在上周四部署了另一个项目的服务后台，这个后台服务消费RabbitMq消息失败了，由于MQ的ACK机制，一直重复传递推送，一直插入失败，一直记录日志，导致两天后存储爆满。

针对于这个问题的实际情况，我首先停止了另外一个Consumer服务，然后清空了容器的日志文件。当然后续也需要针对这个队列的消费者服务进行一些异常的处理，避免此类情况发生。

清空Docker容器的日志文件，truncate截断命令。 truncate -s 0 /var/lib/docker/containers/*/*-json.log 清理docker 容器下面的log 执行完后，空间已经腾出，根目录恢复到之前的水平。

这次事件暴露了很多个人的问题： （1）消息队列的ACK机制，例如后台出现异常时不会进行确认，会重复发送执行，Consumer端的不当处理可能会导致服务器问题，因此需要加深对ACK机制的深入。 （2）Linux的磁盘分区和挂载需要加深学习。