问题解决：记录一次Linux服务器根目录突然爆满

一、出问题了

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

二、首要怀疑

因为看到后台不停的打印出日志，后台日志服务使用到了Kafka，日志也显示Kafka的一些警告信息。因此我首先想到是不是队列一直消费失败，然后不断尝试、不断报错、不停打印日志写入导致空间爆满。
进入到项目后台的容器编排配置目录，使用

du -sh *

查看空间占用，删除了Kafka、ES、RabbitMQ等一些中间件的日志后仅仅腾出了2G空间，服务部署也有俩月了，感觉这个大小属于正常情况，因此根目录爆满可能并非这个原因。

三、根目录内容逐项排查

（1）目录排查：根目录 /

此处排查主要使用

du -sh

命令，大概介绍参考：

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

使用

du -sh *

命令查看根目录下所有子目录的大小

[root@localhost /]# du -sh *0       bin
149M    boot
0       dev
41M     dockercompose
8.8G    dockerfile
37M     etc
36G     home
32K     html
0       lib
0       lib64
0       media
0       mnt
0       opt
du: 无法访问"proc/3514/task/3514/fd/4": 没有那个文件或目录
du: 无法访问"proc/3514/task/3514/fdinfo/4": 没有那个文件或目录
du: 无法访问"proc/3514/fd/4": 没有那个文件或目录
du: 无法访问"proc/3514/fdinfo/4": 没有那个文件或目录
0       proc
1.2G    publish
205M    root
763M    run
0       sbin
0       srv
0       sys
4.0K    tmp
3.1G    usr
51G     var

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

• dockerfile目录：一些docker的本地镜像文件，大小合理；
• home目录：进行了项目上三维模型数据的数据挂载，大小合理；
• var目录：记忆中并没有对这个目录存放了什么数据，不合理！

（2）目录排查：/var

为什么 /var 目录占用了51个G？本身根目录是

/dev/mapper/centos-root

的挂载点，因此我怀疑激增的数据就是在var目录中，使用

du -sh *

命令进行排查

[root@localhost /]# cd var[root@localhost var]# ls
adm  cache  crash  db  empty  games  gopher  kerberos  lib  local  lock  log  mail  nis  opt  preserve  run  spool  tmp  yp
[root@localhost var]# du -sh *0       adm
204M    cache
0       crash
8.0K    db
0       empty
0       games
0       gopher
0       kerberos
51G     lib
0local0       lock
41M     log
0       mail
0       nis
0       opt
0       preserve
0       run
16K     spool
0       tmp
0       yp

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

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

（3）目录排查：/var/lib

进入到/var/lib下再次执行

du -sh *

命令进行排查

[root@localhost var]# cd lib/[root@localhost lib]# ls
alternatives  chrony      dbus      docker  initramfs  machines  NetworkManager  plymouth  postfix  rpm-state  selinux    systemd  tuned   yum
authconfig    containerd  dhclient  games   logrotate  misc      os-prober       polkit-1  rpm      rsyslog    stateless  tpm      vmware  zerotier-one
[root@localhost lib]# du -sh *
28K     alternatives
0       authconfig
4.0K    chrony
1.1M    containerd
0       dbus
0       dhclient
51G     docker0       games
0       initramfs
4.0K    logrotate0       machines
0       misc
16K     NetworkManager
0       os-prober
4.0K    plymouth
0       polkit-1
4.0K    postfix
110M    rpm0       rpm-state
4.0K    rsyslog
0       selinux
0       stateless
64K     systemd
0       tpm
0       tuned
0       vmware
11M     yum
120K    zerotier-one

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

（4）目录排查：/var/lib/docker

进入到var/lib/docker目录，再次执行

du -sh *

命令进行排查

[root@localhost lib]# cd docker[root@localhost docker]# du -sh *
416K    buildkit
18G     containers
24M     image
172K    network
32G     overlay2
0       plugins
0       runtimes
0       swarm
0       tmp
0       trust
1.4G    volumes

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

四、Docker的相关排查

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

（1）Docker空间分布分析 docker system df

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

docker system df 

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

执行命令得到如下输出：

[root@localhost lib]# docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          342413.85GB   6.31GB (45%)
Containers      24241.128GB   0B (0%)
Local Volumes   1492.086GB   536.9MB (25%)
Build Cache     130         0B        0B

其中”RECLAIMABLE“表示可回收的
很奇怪的一件事，一共有34个镜像，但是使用的只有24个，是不是说那些没有使用到的镜像就可以删除掉腾出空间了？
使用docker system df -v 命令查看docker空间占用的详细参数

通过”CONTAINERS“列（此镜像的容器数）发现一些镜像并没有使用到，出现这种未使用的镜像的原因是：
（1）项目需求制作服务的基础镜像时形成的冗余镜像，可删除
（2）原本由docker命令部署的容器改为了使用docker-compose部署后之前部署时拉取的重复镜像，可删除
但我觉得这些都不是一个周末后”/“目录从67%到100%爆满的原因。
先清理一下Docker的冗余吧，docker提供了

docker system prune

空间清理命令

docker system prune 自动清理说明：

• 该指令默认会清除所有如下资源： - 已停止的容器（container）- 未被任何容器所使用的卷（volume）- 未被任何容器所关联的网络（network）- 所有悬空镜像（image）。
• 该指令默认只会清除悬空镜像，未被使用的镜像不会被删除。
• 添加 -a 或 --all 参数后，可以一并清除所有未使用的镜像和悬空镜像。
• 可以添加 -f 或 --force 参数用以忽略相关告警确认信息。
• 指令结尾处会显示总计清理释放的空间大小

Docker 空间使用分析与清理

[root@localhost lib]# docker system prune
WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all dangling images
  - all dangling build cache

Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B

因为记录之前做了一次清理，当时清理腾出了不到1g的空间。添加

-a

参数清除所有未使用的镜像和悬空镜像，腾出大约2.49g的空间，但是距离两天前根目录69%的存储还是有一定距离。

此时再使用

docker system df

命令查看docker的空间分析信息是这样的，似乎镜像于容器本身没什么问题了

[root@localhost docker]# docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          242411.36GB   796.3MB (7%)
Containers      24241.129GB   0B (0%)
Local Volumes   1492.086GB   536.9MB (25%)
Build Cache     00         0B        0B

再次执行

du -sh *

命令进行排查

[root@localhost docker]# du -sh *
404K    buildkit
19G     containers
21M     image
172K    network
30G     overlay2
0       plugins
0       runtimes
0       swarm
0       tmp
0       trust
1.4G    volumes

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

（2）Docker的overlayer2目录

Docker目录为：

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

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

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

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

[root@localhost containers]# cd 8f64f9ed27cc12e5233f877a22a461b7b47d11525cd8069b087333835f9ff802/[root@localhost 8f64f9ed27cc12e5233f877a22a461b7b47d11525cd8069b087333835f9ff802]# ls
8f64f9ed27cc12e5233f877a22a461b7b47d11525cd8069b087333835f9ff802-json.log  config.v2.json   hostname  mounts       resolv.conf.hash
checkpoints                                                                hostconfig.json  hosts     resolv.conf

其中日志文件以

容器ID-json.log

的结构命名，例如8f64f9ed27cc12e5233f877a22a461b7b47d11525cd8069b087333835f9ff802-json.log

（3）Docker日志清理

在/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的磁盘分区和挂载需要加深学习。