一、背景

系统运行期间，客户突然反馈上传文档传不上去。研发立马排查日志，发现日志中出现大量的“No space avaliable on disk”，下意识应用服务器磁盘满了，赶快连上服务器查看磁盘空间占用情况：

黑人问号脸？？磁盘占用还好啊，都是10%以下，咋会满呢？联系我后，我说运行“df -i”试试，果不其然：

为什么“df -Th”看tmp磁盘还好，看“df -i”时就占用100%呢？

二、原理分析：

“df -Th”主要是以磁盘物理空间占用情况以用户易读易理解的方式进行输出；

而“df -i”则主要显示文件系统inode的使用情况，inode是文件系统用于存储文件元数据的数据结构，每个文件和目录都会占用一个inode，这个命令对于检查系统是否因为inode耗尽而无法创建新文件非常有用。

综合以上线索，的确是因为inode耗尽，导致的业务系统上传文件失败的问题。

三、如何解决：

快速清理tmp，先恢复业务：

-- 快速清理1天前的tmp文件

find /tmp -mtime +1 -name "tomcat*" | xargs rm -rf

默认/tmp目录操作系统配置的是30天自动清理一次，该时间可以自行调整，不同linux操作系统通过不同方式来调整：

在 Debian-like 的系统，启动的时候才会清理 (规则定义在 /etc/default/rcS )

在 RedHat-like 的系统，按文件存在时间定时清理 (RHEL6 规则定义在 /etc/cron.daily/tmpwatch ; RHEL7 以及 RedHat-like with systemd 规则定义在 /usr/lib/tmpfiles.d/tmp.conf , 通过 systemd-tmpfiles-clean.service 服务调用)

在 CentOS 里，是按文件存在时间清理的 (通过 crontab 的配置 /etc/cron.daily 定时执行 tmpwatch 来实现)

在 Gentoo 里也是启动清理，规则定义在 /etc/conf.d/bootmisc ，但 Gentoo 就是不走寻常路

四、问题复盘：

分析为什么tmp目录会涨的如此快，可以通过“lsof /tmp”来分析哪些进程在持有/tmp目录下的文件资源不释放。

通过这个命令，我分析出来我们业务系统主要就是日志分片太频繁，且在一台服务器上部署应用服务太多，多个系统服务同时产生大量分片的日志文件，短时间之内快速把tmp目录的inode资源耗尽。