目录
一、问题背景
由于生产环境所部署的服务版本太老,加上部署时磁盘规划不合理,导致近几天服务日志增加的很快,导致/data下磁盘打满,影响生产服务运行。需要持续观察进行手动清理,释放磁盘空间。
二、问题描述
以防万一,就把日志移动备份到另外磁盘空间大的目录,移动备份完成后发现原有磁盘目录空间仍然显示磁盘占用率将近100%,未能得到释放,就做出以下操作
三、问题解决
1、检查服务器占用硬盘资源的文件
[root@nc-ftp02 ~]# df -hP
Filesystem Size Used Avail Use% Mounted on
/dev/xvda2 99G 4.2G 90G 5% /
tmpfs 3.9G 228K 3.9G 1% /dev/shm
/dev/xvda1 380M 66M 294M 19% /boot
/dev/xvda5 386G 290G 77G 80% /data
[root@nc-ftp02 ~]# cd /data/
[root@nc-ftp02 data]# ls
backup data_bak ftp lost+found script
[root@nc-ftp02 data]# du -sh *
4.1G backup
12G data_bak
813M ftp
16K lost+found
5.0G nchome
16K script
注意:查看后,发现data目录下,并无大文件存在,备份目录下面只保留了2个月的数据,所以问题依旧存在
这时想起来,在Linux或者Unix系统中,通过rm或者文件管理器删除文件将会从文件系统的文件夹结构上解除链接(unlink).然而假设文件是被打开的(有一个进程正在使用),那么进程将仍然能够读取该文件,磁盘空间也一直被占用。而我删除的是备份和log文件删除的时候文件应该正在被使用;
2、查看删除文件被占用的具体情况
[root@nc-ftp02 data]# lsof -n /data |grep deleted
sh 8757 root 1w REG 202,5 287246420690 12 /data/nohup.out (deleted)
sh 8757 root 2w REG 202,5 287246420690 12 /data/nohup.out (deleted)
rsync 28485 root 1w REG 202,5 287246420690 12 /data/nohup.out (deleted)
rsync 28485 root 2w REG 202,5 287246420690 12 /data/nohup.out (deleted)
ssh 28486 root 2w REG 202,5 287246420690 12 /data/nohup.out (deleted)
ssh 28486 root 6w REG 202,5 287246420690 12 /data/nohup.out (deleted)
[root@nc-ftp02 data]# lsof -n /data |grep deleted|awk '{print $2}'
8757
8757
28674
28674
28675
28675
3、如何让进程释放?
[root@nc-ftp02 data]# lsof -n /data |grep deleted|awk '{print $2}'|xargs kill -9
[root@nc-ftp02 data]# lsof -n /data |grep deleted
[root@nc-ftp02 data]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda2 99G 4.2G 90G 5% /
tmpfs 3.9G 228K 3.9G 1% /dev/shm
/dev/xvda1 380M 66M 294M 19% /boot
/dev/xvda5 386G 22G 345G 6% /data
一种方法是用以上操作,kill掉相应的进程,另一种就是停掉使用这个文件的应用,让os自己主动回收磁盘空间。
3.1、如果系统管理员能够熟悉该服务器上相关应用部署和配置,可以通过第一种方法进行释放,我在操作过程,采用的就是kill掉应用中不使用的进程来释放空间;
当linux打开一个文件的时候,Linux内核会为每个进程在/proc/ 『/proc/nnnn/fd/文件夹(nnnn为pid)』建立一个以其pid
为名的文件夹用来保存进程的相关信息,而其子文件夹fd保存的是该进程打开的全部文件的fd(fd:file descriptor)。
kill进程是通过截断proc文件系统中的文件能够强制要求系统回收分配给正在使用的的文件。
仅到管理员确定不会对执行中的进程造成影响时使用。应用程序对这样的方
式支持的并不好,当一个正在使用的文件被截断可能会引发不可预知的问题
3.2、如果环境有非常多进程在使用的这个文件,停掉进程可能带来一定风险,又不在系统管理员控制范围内,建议不要轻易使用kill进行操作;最好原则合适时间停掉相关应用进行释放。
综上所述,问题最终以得到解决!