eaccelerator可能会导致这个问题，因为它将PHP编译成块…我在一个负载很重的网站上使用亚马逊AWS服务器时遇到过这个问题。如果您仍然有问题，可以通过删除/var/cache/eaccelerator中的eaccelerator缓存来释放Inodes。

rm -rf /var/cache/eaccelerator/*

(或者你的缓存目录)

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

/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手动删除了一些会话。

希望这能有所帮助!

对于大量的文件，可以使用RSYNC删除

rsync -a --delete blanktest/ test/

创建空白测试文件夹，其中包含0个文件，命令将与大量文件同步测试文件夹(我已经使用这种方法删除了近500万个文件)。

感谢http://www.slashroot.in/which-is-the-fastest-method-to-delete-files-in-linux

我有同样的问题，通过删除php的目录会话来修复它

rm -rf /var/lib/php/sessions/

如果您使用的是较旧的php版本，它可能在/var/lib/php5下。

使用以下权限重新创建它

mkdir /var/lib/php/sessions/ && chmod 1733 /var/lib/php/sessions/

Debian默认目录权限显示drwx-wx-wt (1733)

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

当df -i说100% Inode使用;

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

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

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

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

/usr/local/cpanel/bin/purge_dead_comet_files