inodes 占用100%的问题及解决方法

情况描述：今天我们邮件服务器收发不了邮件了，而且连接到服务器上开启服务都开不了，起始以为磁盘空间不足，df 看了一下
[root@app]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda6              20G  4.1G   15G  22% /
/dev/sda2              34G   24G  8.6G  74% /app
/dev/sda1             190M   13M  168M   7% /boot
/dev/sda5              30G   14G   14G  51% /data
none                  3.0G     0  3.0G   0% /dev/shm
/dev/sda3              34G   12G   21G  36% /home
/dev/sda7             9.7G  151M  9.1G   2% /tmp

[root@app]# df -ih
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda6               1.3M    196K    1.1M   16% /
/dev/sda2               2.2M    2.0M    218K   91% /app
/dev/sda1                50K      40     50K    1% /boot
/dev/sda5               1.9M     48K    1.8M    3% /data
none                    209K       1    209K    1% /dev/shm
/dev/sda3               2.2M     61K    2.1M    3% /home
/dev/sda7               628K      99    627K    1% /tmp

解决方法：通过以下脚本进行检查，查看到底哪个目录下面的文件最多：

for i in /*; do echo $i; find $i | wc -l; done（如果确定是某个目录下面，则/转换为该目录绝对路径，如/var/spool，则使用for i in /var/spool/*; do echo $i; find $i | wc -l; done）

关于inodes占用100%的问题及解决方法
[root@app]# for i in /app/*;do echo $i;find $i|wc -l;done
/app/savexml
1669250
/app/src
159
/app/TSSBackData
5
/app/ui
352396

/app/savexml/wechar
1669485

/app/savexml/wechar/getxml
825067
/app/savexml/wechar/returnxml
844477

/app/savexml/wechar/getxml/2016
126948
/app/savexml/wechar/getxml/2017
396316
/app/savexml/wechar/getxml/2018
301831

/app/savexml/wechar/returnxml/2016
127818
/app/savexml/wechar/returnxml/2017
398835
/app/savexml/wechar/returnxml/2018
317868

*************************
请确认文件是否可以清除
*************************
cd /app/savexml/wechar/getxml

tar -zcvf 2016.tar.gz 2016

rm -rf 2016

cd /app/savexml/wechar/returnxml

tar -zcvf 2016.tar.gz 2016

rm -rf 2016

最终发现/var/soppl目录最多。然后又进一步确定是/var/spool/amavisd/quarantine 目录下面有上百万个文件，机器已经无法正常显示了,后来百度查看了下这个目录是邮件服务器，处理垃圾邮件活病毒邮件隔离的，明白原因了，删除该目录下所有文件；使用xargs命令来删除数量比较多的文件：

ls | xargs -n 10 rm -rf

执行了大约10多小时之后，最终解决问题。