2018-12-15
昨天工作站还很正常,今天来了公司一看,突然发现进bash提示
last login: Fri Dec 14 18:50.11 2018 from ...
write failed: 设备上没有空间
赶快执行 lsblk 看一下,发现的确是满了
然后在当前用户目录下 ~/ ,执行
$ du -h -d 1
发现这里的空间使用情况正常
然后进根目录执行相同的命令
定位到的问题是
$ cd /var/lib/docker/aufs
$ du -h -d 1
117G ./diff
103M ./layers
315M ./mnt
118G .
发现diff目录下有117G,用docker的命令看一下
$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 169 111 59.8GB 33.65GB (56%)
Containers 12298 1 61.14GB 61.14GB (100%)
Local Volumes 486 145 34.06GB 27.22GB (79%)
Build Cache 0B 0B
既然是docker的问题,那先执行一下清除命令
$ docker system prune -a
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all images without at least one container associated to them
- all build cache
Are you sure you want to continue? [y/N] y
看起来这个命令会清理掉无用的磁盘空间
Total reclaimed space: 120.7GB
而输出也的确是这样的,再看一下磁盘空间
$ df -h
/dev/sda2 438G 185G 231G 45% /
已经明显恢复正常了
但是值得思考的是,之前并没有遇到这个问题,看起来唯一能解释的通的就是最近开始用 docker-compose 来部署本地测试环境,应该是频繁的执行docker-compose up/down 命令导致大量的创建container并且没有清空,这个要注意.
另外,对容器本身可使用的空间也应该加以限制,一般解决方案是通过 Docker daemon 的参数来全局限制单个容器占用空间的大小:
- --storage-opt dm.basesize=20G
表示限制单个容器最多占用 20G 空间,将应用于任何新建容器。
网友评论