我希望有人能给我一些建议。我正在运行 CentOS 6 服务器，过去几天我的磁盘使用量从 60GB 变为 135GB（98% 已满）。我相信问题可能与 PHP 会话目录（/var/lib/php/session）有关，因为这似乎很大（我不能 ls 或 rm），这个目录中肯定有数百万个文件。
如何删除此目录？rm 在这里不起作用，我也尝试过 rsync 替换一个空目录，但这也需要永恒。
如果这是导致问题的原因 - 为什么 PHP 不会自动删除这些文件？
是否有任何日志记录可以将我指向漏洞利用、DDOS 或失败的方向？
谢谢
sudo find /var/lib/php/session -type f -delete会比因为大文件列表几乎不可能sudo rm /var/lib/php/session/*扩展而工作得更好。*听起来您的应用程序正在创建会话，但从不破坏它们。这可能是糟糕的编程和糟糕的环境设置的混合。
如果您想删除这些会话文件，您需要使用 sudo，因为它们可能不属于您的用户。
我不会删除整个会话目录。
另一件事是将 PHP Session 超时调整为更小的间隔。
Ubuntu 的默认配置是 PHP 不会使会话过期，但有一个 cron 作业会删除旧文件。对此进行全面讨论需要一些时间（恕我直言，这是一个非常糟糕的主意），但是我不知道 Redhat 采取了类似的方法。
您尚未提供会话配置的任何详细信息。这种情况可能由于 session.gc_probability、session.gc_divisor 或 session.gc_maxlifetime 中的任何一个值而出现。一旦按照其他答案中的描述清除了文件，设置默认值 1、100 和 1440 应该可以确保合理的稳态系统。
您还没有说您在系统上看到了多少并发会话、它们的平均大小，也没有说它们存储在哪个文件系统上。如果您预计超过 300 个会话（取决于文件系统），您应该考虑使用目录树而不是单个目录来存储文件；为 session.save_path 添加 1 或 2 前缀（假设这不是支持服务器集群的 NFS 服务器，在这种情况下，您应该迁移到不同的体系结构）。
Matt 提到它可能是 selinux 配置。如果这允许创建文件但从不删除。虽然这是可能的，但这表明系统上的配置严重混乱。如果是这种情况（检查您的审核日志），那么您可能应该进行全新安装并在其上恢复您的应用程序。
这不太可能与糟糕的编程有关。