共计 3072 个字符,预计需要花费 8 分钟才能阅读完成。
问题阐明
IDC 里的一台服务器的 / 分区使用率爆满了!已达到 100%!经查看发现有个文件过大(80G),于是在跟无关共事确认后 rm - f 果决删除该文件。然而发现删除该文件后,/ 分区的磁盘空间压根没有释放出来,使用率还是 100%!这是为什么呢?
[root@linux-node1 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
58G 7.8G 47G 100% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
/dev/vda1 190M 72M 108M 40% /boot
起因剖析:
在 Linux 零碎中,通过 rm 或者文件管理器删除文件,只是将它会从文件系统的目录构造上解除链接 (unlink),也就是说只是删除了文件和系统目录构造的链接;
如果文件在删除时是被关上的(有一个过程正在应用该文件,文件被过程锁定或者有过程始终在向这个文件写数据等)状态,那么过程将依然能够读取该文件,也就是说没有删除掉文件在读取的状态,所以磁盘空间也就会始终被占用。
一个文件在文件系统中的寄存分为两个局部:数据局部和指针局部,指针位于文件系统的 meta-data 中,数据被删除后,这个指针就从 meta-data 中革除了,而数据局部存储在磁盘中,数据对应的指针从 meta-data 中革除后。
文件数据局部占用的空间就能够被笼罩并写入新的内容,之所以呈现删除文件后,空间还没开释,就是因为有过程还在始终向这个文件写入内容,导致尽管删除了文件,但文件对应的指针局部因为过程锁定,并未从 meta-data 中革除,而因为指针并未被删除,那么零碎内核就认为文件并未被删除,因而通过 df 命令查问空间并未开释也就难能可贵了。
解决措施有以下几种
- 通过 lsof|grep deleted 命令获取到曾经被删除然而依然被应用程序占用的文件列表,而后 kill 掉还在占用所删除文件的过程。须要留神的是:如果有很多过程都在应用所删除文件,那么采纳第 1 种形式 kill 过程就有点麻烦了,而且危险也比拟大。
因为 kill 过程是通过截断 proc 文件系统中的文件能够强制要求零碎回收调配给正在应用的的文件。必须要确定不会对运行中的过程造成影响时能力应用,应用程序对这种形式反对的并不好,当一个正在应用的文件被截断可能会引发不可预知的问题。
- 或停掉或重启应用这个所删除文件的利用,让 OS 主动回收磁盘空间。
- 也能够重启操作系统,不过这并不是最好的办法
- 看待这种过程不停对文件写日志的操作,要开释文件占用的磁盘空间,最好的办法是在线清空这个文件。通过这种办法,磁盘空间岂但能够马上开释,也可保障过程持续向文件写入日志。
在线清空文件(比方 /home/wangshibo.log)的形式:
a)# echo " " > /home/wangshibo.log
b)# cat /dev/null > /home/wangshibo.log
c)# > /home/wangshibo.log
还有一种磁盘空间应用问题的景象:明明应用 df - h 命令查看磁盘空间使用率不算高,还有很多空余空间,然而创立文件或写入数据时始终报错磁盘写满:” no space left on device”!
个别这种问题都是因为分区目录下 deleted 删除后的资源空间没有真正释放出来导致的, 具体解决流程如下:
- 先 df -lh 查看一下磁盘应用情况, 发现 /data 分区下的 Used 已用空间很大, 然而理论查看并没有占用那么大的空间!
- 找到被删除文件所在的分区, 比方 /data 分区
- 查看被删除了的所有文件:lsof -n /data |grep deleted
- 杀死这些文件的 delete 过程, 开释空间: lsof -n /data |grep deleted|awk ‘{print $2}’|xargs kill -9
- 接着再运行 lsof -n /data |grep delete,应该就没有后果了。
- 留神: 刚杀死 deleted 过程时, df - h 查看 /data 分区, Used 已用空间可能时霎时显示过大, 但随着 deleted 过程杀死, 资源逐步开释, /data 分区下的 Used 已用空间会逐步变小, Avail 可用空间会逐步变大 )
大多数文件系统都会保留一部分空间留作紧急情况时用(比方硬盘空间满了),这样能保障有些要害利用(比方数据库)在硬盘满的时候有点余地,不致于马上就 crash,给监控零碎和管理员一点工夫去觉察。不过有时候这部分预留的硬盘空间不必的话有点节约。
在 Linux 零碎中,ext2、ext3、ext4 文件系统上通常会默认预留 5%的磁盘空间,比方磁盘如果是 2TB,这就意味着有 100GB 的空间会被预留下来,这样的话会不会显得有点节约了。能够通过 ”tune2fs” 命令来扭转 5%的默认设置,比方只预留 2%的空间。然而不倡议设成 0%,事实环境中这样做不平安。
[root@ss-server ~]# df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/vda1 ext4 41151808 4962148 34076228 13% /
devtmpfs devtmpfs 1931468 0 1931468 0% /dev
tmpfs tmpfs 1941204 0 1941204 0% /dev/shm
tmpfs tmpfs 1941204 652 1940552 1% /run
tmpfs tmpfs 1941204 0 1941204 0% /sys/fs/cgroup
tmpfs tmpfs 388244 0 388244 0% /run/user/0
[root@ss-server ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 40G 4.8G 33G 13% /
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 1.9G 620K 1.9G 1% /run
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
tmpfs 380M 0 380M 0% /run/user/0
比方下面 ”/” 分区是 ext4 文件系统,默认零碎预留了 5% 也就是 2G 的空间。当初能够通过 ”tune2fs” 命令将零碎预留空间改为 2%。
[root@ss-server ~]# tune2fs -m 2 /dev/vda1
tune2fs 1.42.9 (28-Dec-2013)
Setting reserved blocks percentage to 2% (209704 blocks)
执行后,发现 ”/” 分区腾出了 1G 的空间,这时零碎预留空间也就是 2% 了。
[root@ss-server ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 40G 4.8G 34G 13% /
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 1.9G 620K 1.9G 1% /run
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
tmpfs 380M 0 380M 0% /run/user/0
留神:Linux 下只有 ext2、ext3、ext4 文件系统时,零碎才会默认预留 5% 的磁盘空间。如果文件系统是 xfs、tmpfs、devtmpfs、overlay 等,则零碎默认不会预留磁盘空间。
福利:豆花同学为大家精心整顿了一份对于 linux 和 python 的学习材料大合集!有须要的小伙伴们,关注豆花集体公众号:python 头条!回复关键词“材料合集”即可收费支付!