Docker垃圾回收机制
由Docker垃圾回收机制引发的一场血案
今天早晨,在我还没睡醒的时候,我们团队中的一名成员就告诉我,我写的微服务中,上传头像的那个没法用.而我在发布之前,已经测试过可以使用了.那这到底是怎么回事呢?
首先,我重新执行了一遍测试过程,发现生产服务器上的微服务上的这个上传头像的接口确实不可用.
然后,我在本地启动了一下微服务,同样测试了一下微服务.发现还是不可用.同时,通过本地打印错误日志,发现错误是在执行保存图片这个写操作的时候:Error: socket hang up.
开始以为是网络故障,但是访问网页以及通过SSH登陆到那台服务器都没有问题.
既然不是网络故障的原因.那到底是什么导致的呢?
通过查看Couchdb容器的日志,我发现了有如下错误日志:
你能从中看出是什么原因吗?错误就隐藏在这中间.
同样,我也是第一次使用CouchDB这个数据库,这个错误栈让我也很懵逼.这是啥意思?
这个看不懂,只好根据Error: socket hang up这个错误来猜了.猜测是打开数据库的连接太多.
顺着这个主线,通过查看CouchDB官方文档,我们发现默认的最大连接数就是1024,有图有真相:
![](http://upload-images.jianshu.io/upload_images/4108852-4cbe7d0b1c13ac33.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
通过curl -X GET http://server_ip:5984/_stats | json_reformat这条命令,我发现,当前数据库的总共HTTP请求才有49个:
![](http://upload-images.jianshu.io/upload_images/4108852-9a2dae1160bd5e52.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
也不是达到了最大连接数,导致不能创建新的连接的原因.那是因为什么呢?
还记得上面的错误信息吗?其中有一条是enospc.那这个到底是什么意思呢?No space.没有空间.
这就很容易解释为什么写操作会报错,而读操作却正常运行的原因了.
那为什么会没有空间呢?有两个原因,一是磁盘没有空间了,二是没有Inode可用了.
CouchDB本身是在一个容器中运行,它使用的是主机的资源.所以,很有可能是主机没有空间了.
一个容器中的所有的东西,都是存放在/var/lib/docker文件夹下的相应的文件系统中的.我这里因为是ubuntu系统,所以是存放在/var/lib/docker/aufs/mnt这个目录中.
而这个目录又是挂载到主机的/目录下.
所以,只要/var/lib/docker/aufs/mnt这个目录中存满了东西,主机上的/也就没有空间了.你在主机上进行任何写操作都不会成功.
运行df -h命令,发现果然是/目录中没有空间了.已用100%.
那我们如何来清理/var/lib/docker/aufs/mnt或者/这两个目录,让它们腾出来空间呢?
首先,我想到的是清理掉系统中的不必要的包,使用下面的命令:sudo apt-get autocleansudo apt-get autoremove
然而,并没有什么作用.还是100%.
然后,通过docker ps -a命令,我发现存在着几个已经退出或者被创建但是没有运行的容器.它们占用了一些宝贵的空间.
然后,通过docker rm -f &(docker ps -qf status=exited)和docker rm -f &(docker ps -qf status=created)命令移除那些没用的容器.结果,发现还是不管用.
其实,通过这种方式虽然移除了容器,但是和它们相关的卷并没有移除,我又通过docker volume ls -qf dangling=true | xargs -r docker volume rm命令,移除了那些没用的卷.
上面的删除容器和其相关的卷的命令,我们可以简化为:docker rm -v -f &(docker ps -qf status=exited)
这时候,再通过df -h命令,我们就能看到已用到了82%了:
![](http://upload-images.jianshu.io/upload_images/4108852-116c2dfe914316c8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
因为我这里没有没用的镜像,所以就没有进行移除镜像的操作.
我们为什么命题为”由Docker垃圾回收机制引发的一场血案”呢?因为我一直都以为如果容器被移除掉,其对应的卷也会自动被回收.然而事实证明并没有.
从上图中你也可以看到,我们的这台服务器总容量才20G.实际上,我们不应当使用硬盘容量这么小的服务器来运行Docker容器.
清除了一定的空间,再测试上传头像接口,就可以正常使用了.
出了这次事故,我专门去官网看了看Docker的垃圾回收机制,发现目前官网只提供了针对Docker Registry的垃圾回收机制.而且还是需要手动运行bin/registry garbage-collect [–dry-run] /path/to/config.yml这条命令.
实际上,我们也完全可以自己写一个简单的脚本来进行垃圾回收.Github上也提供了相应的工具,有docker-cleanup-volumes以及其他的卷管理工具.这些我也没试过,请自行查看.