在上面的一个回答中，有人建议会话是inode耗尽的原因，在我们的例子中正是如此。为了补充这个答案，我建议检查php.ini文件并确保session。Gc_probability = 1也是session。gc_除数= 1000和 会话。Gc_maxlifetime = 1440。在我们的案例会议上。Gc_probability等于0，导致了这个问题。

我的情况是我没有inodes了，我已经删除了所有我能删除的东西。

$ df -i
Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/sda1      942080 507361     11  100% /

我使用的是ubuntu 12.04LTS，无法删除旧的linux内核，它占用了大约400,000个inodes，因为apt因为缺少一个包而损坏了。我无法安装新包，因为我没有inodes了，所以我被卡住了。

我最终手动删除了一些旧的linux内核，以释放大约10,000个inode

$ sudo rm -rf /usr/src/linux-headers-3.2.0-2*

这足以让我安装丢失的包并修复我的apt

$ sudo apt-get install linux-headers-3.2.0-76-generic-pae

然后使用apt删除剩余的旧Linux内核

$ sudo apt-get autoremove

现在情况好多了

$ df -i
Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/sda1      942080 507361 434719   54% /

在一次垃圾邮件攻击后，我们在一个HostGator帐户(他对所有主机都设置了inode限制)上遇到过这种情况。它在/root/.cpanel/comet中留下了大量队列记录。如果发生这种情况，你发现你没有空闲的inode，你可以通过shell运行这个cpanel实用程序:

/usr/local/cpanel/bin/purge_dead_comet_files

对于那些使用Docker并最终来到这里的人，

当df -i说100% Inode使用;

只需运行docker rmi $(docker images -q)

它会让你创建的容器(运行或退出)，但会删除所有不再引用的图像，释放一大堆索引节点;我从100%回到了18%

值得一提的是，我在这台机器上使用了大量的CI/CD和docker运行程序。

迟到的回答: 对我来说，是我的会话文件

/var/lib/php/sessions

使用Inodes的。 我甚至无法打开crontab或创建新目录，更不用说触发删除操作了。 因为我使用PHP，所以在本指南中，我复制了示例1中的代码，并设置了cronjob来执行这部分代码。

<?php
// Note: This script should be executed by the same user of web server 
process.

// Need active session to initialize session data storage access.
session_start();

// Executes GC immediately
session_gc();

// Clean up session ID created by session_gc()
session_destroy();
?>

如果您想知道我是如何打开crontab的，那么好吧，我通过CLI手动删除了一些会话。

希望这能有所帮助!

如前所述，如果有很多小文件，文件系统可能会耗尽inode。我提供了一些方法来查找这里包含大多数文件的目录。