记录一次linux磁盘空间满了的排查过程
在xshell使用tab命令时出现报错,查询后得知是磁盘空间满了的原因。在得知错误原因后就开始了排查。
- 首先使用df -h命令查询磁盘的占用结果如下
[root@VM-24-15-centos docker]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 989M 0 989M 0% /dev
tmpfs 1000M 48K 1000M 1% /dev/shm
tmpfs 1000M 620K 999M 1% /run
tmpfs 1000M 0 1000M 0% /sys/fs/cgroup
/dev/vda1 40G 39G 0 100% /
overlay 40G 39G 0 100% /var/lib/docker/overlay2/1c672efe3e533193890bbf4b83786812b757507e790d0212dab1c9bb9f6ccf5d/merged
shm 64M 0 64M 0% /var/lib/docker/containers/78f756564c97152b14f781a2c2aabc985f3c42b39da2476a81423e091cefaf11/mounts/shm
overlay 40G 39G 0 100% /var/lib/docker/overlay2/c3031e9c5a07e7ce273ad8d353498c72056dc7965c262c7ac0d165f35bd49a58/merged
shm 64M 0 64M 0% /var/lib/docker/containers/7818367139cfef5cfa20ad7ddcdbbf8e85b5cdce5963c1df7ba847da3a519750/mounts/shm
tmpfs 200M 0 200M 0% /run/user/0
从以上结果我们可以看出主要是Docker的overlay文件系统占用了大量空间,Docker的overlay文件系统,用于存储Docker容器和镜像的层。
- 接下来进入对应的目录使用
du -h --max-depth=1
查看占用空间较大的目录
du -h --max-depth=1
389M ./volumes
20K ./builder
4.0K ./swarm
20K ./plugins
3.0G ./overlay2
32G ./containers
4.0K ./runtimes
72K ./network
8.3M ./image
220K ./containerd
4.0K ./tmp
4.0K ./trust
35G .
可以看出是containers目录占用了很大的空间,我们继续排查。
- 进入到文件夹内部继续查看占用大小
du -h --max-depth=1
150M ./78f756564c97152b14f781a2c2aabc985f3c42b39da2476a81423e091cefaf11
32G ./
32G .
发现是容器id为7818367139…占用了很大的内存,我们使用docker的命令查看以下容器信息,使用如下命令:
docker ps -qa | \
xargs docker inspect --format '{{.State.Pid}}, {{.Id}}, {{.Name}}, {{.GraphDriver.Data.WorkDir}}' | \
grep "7818367139cfef5cfa20ad7ddcdbbf8e85b5cdce5963c1df7ba847da3a519750"
这个命令是一个Linux管道命令,用于查找具有特定图层ID的Docker容器的信息。该命令可以分为四个部分,下面我们逐一解释:
1、docker ps -qa: 这个命令列出所有Docker容器的ID,包括正在运行和已停止的容器。-q 参数表示仅显示容器ID,-a 参数表示显示所有容器。
2、xargs docker inspect --format ‘{{.State.Pid}}, {{.Id}}, {{.Name}}, {{.GraphDriver.Data.WorkDir}}’: 这个命令使用 xargs 从上一个命令接收容器ID,并将它们作为参数传递给 docker inspect 命令。docker inspect 命令用于获取Docker对象(如容器、镜像等)的详细信息。–format 参数指定了一个Go模板,用于格式化输出结果。在这里,输出包含容器的进程ID(.State.Pid),容器ID(.Id),容器名称(.Name)和工作目录(.GraphDriver.Data.WorkDir)。
3、grep “7818367139cfef5cfa20ad7ddcdbbf8e85b5cdce5963c1df7ba847da3a519750”: 这个命令使用 grep 在上一个命令的输出中搜索特定的图层ID。如果找到匹配项,grep 将输出包含该ID的行。
综上所述,这个命令用于查找具有特定图层ID的Docker容器,并输出其进程ID、容器ID、名称和工作目录。
输入命令后结果如下:
18611, (进程ID)
7818367139cfef5cfa20ad7ddcdbbf8e85b5cdce5963c1df7ba847da3a519750,(容器ID)
/kibana,(容器名称)
/var/lib/docker/overlay2/c3031e9c5a07e7ce273ad8d353498c72056dc7965c262c7ac0d165f35bd49a58/work(工作目录)
可以发现是kibana导致的进入内部发现是一个log文件导致的,进入文件内部后发现可能是kinbana一直请求es链接,但是我并没有启动es服务导致一直在生成日志,清空日志,至此问题排查结束。