物理机磁盘空间都去哪里了

磁盘爆掉的几种情况

1. 系统磁盘没有空间，解决办法：删掉 /var/log/ 下边的带日期的日志，清空 /var/log/messages 内容
2. 容器使用的大磁盘空间不够，又有三个地方会使用大量的磁盘
   • 容器内部日志非常大，处理办法见方法一
   • 容器内部产生非常多或者非常大的文件，但是这个文件的位置又通过volume 挂载到了物理机上，处理办法见方法二
   • 对特别老的部署环境，还有可能是容器的系统日志没有限制大小，处理办法见方法三

现场的同学按如下方法依次检查

方法零： 检查系统根目录下每个文件夹的大小

sudo du / -lh --max-depth=1 --exclude=overlay --exclude=proc

看看除了容器之外有没有其它目录使用磁盘特别大，如果有那么一层层进去通过du命令来查看，比如：

#sudo du / -lh --max-depth=1 --exclude=overlay --exclude=proc
16K	/dev
16K	/lost+found
4.0K	/media
17G	/home
136M	/boot
832K	/run
1.9G	/usr
75M	/tmp
12K	/log
8.5G	/var
4.0K	/srv
0	/proc
22M	/etc
84G	/root
4.0K	/mnt
508M	/opt
0	/sys
112G	/

那么这个案例中应该查看 /root下为什么用掉了84G（总共用了112G）， 先 cd /root 然后执行： sudo du . -lh –max-depth=1 –exclude=overlay 进一步查看 /root 目录下每个文件夹的大小

如果方法零没找到占用特别大的磁盘文件，那么一般来说是容器日志占用太多的磁盘空间，请看方法一

方法一： 容器内部日志非常大（请确保先按方法零检查过了）

在磁盘不够的物理机上执行如下脚本：

sudo docker ps -a -q >containers.list

sudo cat containers.list | xargs sudo docker inspect $1 | grep merged | awk -F \" '{ print $4 }' | sed 's/\/merged//g' | xargs sudo du  --max-depth=0 $1 >containers.size 

sudo paste containers.list containers.size | awk '{ print $1, $2 }'  | sort -nk2 >real_size.log

sudo tail -10 real_size.log  | awk 'BEGIN {print "\tcontainer     size\tunit"} { print NR":\t" $0"\t kB" }' 

执行完后会输出如下格式：

   	container     size	unit
1:	22690f16822f 3769980	 kb
2:	82b4ae98eeed 4869324	 kb
3:	572a1b7c8ef6 10370404	 kb
4:	9f9250d98df6 10566776	 kb
5:	7fab70481929 13745648	 kb
6:	4a14b58e3732 29873504	 kb
7:	8a01418b6df2 30432068	 kb
8:	83dc85caaa5c 31010960	 kb
9:	433e51df88b1 35647052	 kb
10:	4b42818a8148 61962416	 kb

第二列是容器id，第三列是磁盘大小，第四列是单位， 占用最大的排在最后面

然后进到容器后通过 du / –max-depth=2 快速发现大文件

方法二： 容器使用的volume使用过大

$sudo du -l /data/lib/docker/defaultVolumes --max-depth=1 | sort -rn
456012884	/data/lib/docker/defaultVolumes
42608332	/data/lib/docker/defaultVolumes/task_3477_g0_ark-metadb_miniDBPaaS-MetaDB_1
32322220	/data/lib/docker/defaultVolumes/task_3477_g0_dbpaas-metadb_dbpaas_1
27461120	/data/lib/docker/defaultVolumes/task_3001_g0_ark-metadb_miniDBPaaS-MetaDB_1
27319360	/data/lib/docker/defaultVolumes/task_36000_g0_ark-metadb_miniDBPaaS-MetaDB
27313836	/data/lib/docker/defaultVolumes/task_3600_g0_dbpaas-metadb_minidbpaas
27278692	/data/lib/docker/defaultVolumes/task_3604_g0_ark-metadb_miniDBPaaS-MetaDB_1
27277004	/data/lib/docker/defaultVolumes/task_3603_g0_ark-metadb_miniDBPaaS-MetaDB_1
27275736	/data/lib/docker/defaultVolumes/task_3542_g0_ark-metadb_miniDBPaaS-MetaDB
27271428	/data/lib/docker/defaultVolumes/task_3597_g0_ark-metadb_miniDBPaaS-MetaDB
27270840	/data/lib/docker/defaultVolumes/task_3603_g0_dbpaas-metadb_minidbpaas_1
27270492	/data/lib/docker/defaultVolumes/task_3603_g0_dbpaas-metadb_minidbpaas
27270468	/data/lib/docker/defaultVolumes/task_3600_g0_ark-metadb_miniDBPaaS-MetaDB
27270252	/data/lib/docker/defaultVolumes/task_3535_g0_ark-metadb_miniDBPaaS-MetaDB
27270244	/data/lib/docker/defaultVolumes/task_3538_g0_ark-metadb_miniDBPaaS-MetaDB
27270244	/data/lib/docker/defaultVolumes/task_3536_g0_ark-metadb_miniDBPaaS-MetaDB
25312404	/data/lib/docker/defaultVolumes/task_3477_g0_dncs-server_middleware-dncs_2

/data/lib/docker/defaultVolumes 参数是方舟默认volume存放的目录（一般是docker的存储路径下 –graph=/data/lib/docker) ，第一列是大小，后面是容器名

volume路径在物理机上也有可能是 /var/lib/docker 或者 /mw/mvdocker/ 之类的路径下，这个要依据安装参数来确定，可以用如下命令来找到这个路径：

sudo systemctl status docker -l | grep --color graph

结果如下，红色参数后面的路径就是docker 安装目录，到里面去找带volume的字眼：

找到 volume很大的文件件后同样可以进到这个文件夹中执行如下命令快速发现大文件：

du . --max-depth=2

方法三 容器的系统日志没有限制大小

这种情况只针对2017年上半年之前的部署环境，后面部署的环境默认都控制了这些日志不会超过150M

按照方法二的描述先找到docker 安装目录，cd 进去，然后 ：

du ./containers --max-depth=2

就很快找到那个大json格式的日志文件了,然后执行清空这个大文件的内容：

echo '' | sudo tee 大文件名

一些其他可能占用空间的地方

• 机器上镜像太多，可以删掉一些没用的： sudo docker images -q | xargs sudo docker rmi
• 机器上残留的volume太多，删：sudo docker volume ls -q | xargs sudo docker volume rm
• 物理文件被删了，但是还有进程占用这个文件句柄，导致文件对应的磁盘空间没有释放，检查： lsof |　grep deleted 如果这个文件非常大的话，只能通过重启这个进程来真正释放磁盘空间

---

检查是否restart能支持只重启deamon，容器还能正常运行：

$sudo docker info | grep Restore
Live Restore Enabled: true