问题现象
df
命令获知,根分区使用率竟高达81%,而根分区总大小仅为26GB
[root@prd-ds-tms-web02 logs]# df -hT Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/VolGroup-lv_root ext4 26G 20G 4.9G 81% / tmpfs tmpfs 1.9G 0 1.9G 0% /dev/shm /dev/sda1 ext4 477M 74M 378M 17% /boot /dev/mapper/app_vg0-app_lv0 ext4 9.6G 3.4G 5.7G 38% /app /dev/mapper/data_vg0-data_lv0 ext4 29G 347M 27G 2% /appdatadu -sh ./*
命令获知是/var/lib/AnyBackup/logs/下的日志文件过大导致的异常,前几日的文件都正常,但是前天日志文件有2GB,昨天的日志竟高达17GB,鉴于是生产系统,为保证平台稳定性,在确认可以删除后,立即将该日志删除,再次执行df
命令,但发现磁盘空间并未释放
[root@prd-ds-tms-web02 logs]# df -hT Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/VolGroup-lv_root ext4 26G 20G 4.9G 81% / tmpfs tmpfs 1.9G 0 1.9G 0% /dev/shm /dev/sda1 ext4 477M 74M 378M 17% /boot /dev/mapper/app_vg0-app_lv0 ext4 9.6G 3.4G 5.7G 38% /app /dev/mapper/data_vg0-data_lv0 ext4 29G 347M 27G 2% /appdata解决思路
如果进程一直在跑,就会不断的往其日志写入数据(如果有),即便将文件的数据部分删除,文件的指针由于被进程锁定,依旧存在于文件系统元数据(meta-data)中而并未被删除,因此Linux内核认为文件并未被删除,通过df命令查询空间并未释放也就是情理之中的事情了。
处理故障
ps
命令,可以发现AnyBackupClient有一个daemon在后台运行
[root@prd-ds-tms-web02 logs]# ps aux |grep AnyBackup root 5695 0.0 0.6 611960 24064 ? Sl May02 33:38 /usr/src/AnyBackupClient/app/bin/esfdaemon -f clientd.config root 26965 0.0 0.0 103324 896 pts/0 S+ 09:10 0:00 grep AnyBackupkill
命令将其杀死,然后马上观察系统磁盘
[root@prd-ds-tms-web02 logs]# kill -9 5695 [root@prd-ds-tms-web02 logs]# ps aux |grep AnyBackup root 26985 0.0 0.0 103320 896 pts/0 S+ 09:10 0:00 grep AnyBackup [root@prd-ds-tms-web02 logs]# df -hT Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/VolGroup-lv_root ext4 26G 3.1G 22G 13% / tmpfs tmpfs 1.9G 0 1.9G 0% /dev/shm /dev/sda1 ext4 477M 74M 378M 17% /boot /dev/mapper/app_vg0-app_lv0 ext4 9.6G 3.4G 5.7G 38% /app /dev/mapper/data_vg0-data_lv0 ext4 29G 347M 27G 2% /appdata总结