我偶尔在我们的网络服务器上遇到以下错误：
警告：session_start()：open(/tmp/sess_7ifl201pvdd91rr6tr4015n5k4, O_RDWR) 失败：设备 (28) 上没有剩余空间，位于 /home/some/script/on/my/site/script.php 的第 ## 行
我的服务器管理员告诉我，这一定是网站上的某些东西导致了这种情况，比如有人通过 PHP 上传了一个大文件。但我有点怀疑，因为这种情况是最近几天才开始发生的。
所以，我想知道是否有其他人知道为什么会发生这种情况？我正在运行 lightspeed（不是 apache），centos。如果需要更多信息，请告诉我。
答案1
如果问题在于客户端的上传量很大，你可以通过设置 LimitRequestBody 选项来缓解这个问题（请参阅http://httpd.apache.org/docs/2.2/mod/core.html#LimitRequestBody- litespeed 声称与 Apache 兼容，因此它也应该可以在 Apache 上运行，如果不行，您需要查看其文档）。但这只会限制单个请求 - 同时进行大量上传仍然可能会填满临时存储。
保存的卷有多大/tmp？它是专用的/tmp还是与其他区域共享的？将的输出添加到您的问题中会很有帮助df -h。如果您没有单独的文件系统，/tmp那么其他地方可能会填满该卷。
我建议在服务器上添加一些监控功能。我使用收集关注事物和稍微改变的版本这个脚本从记录的数据中生成漂亮的图片 - 还有其他几个流行的选项也可以完成同样的工作。你可以要求它监视文件系统空间使用+空闲（使用这个模块)，那么您将看到您的错误是否对应于填充时的句点/tmp。
如果文件系统有足够的空间，并且其 inode 用尽，则文件系统可能会“满”。如果是这种情况，那么您可以重新创建文件系统，增加 inode 的数量。这通常只会在您拥有大量小文件时才会成为问题，因为创建文件系统时的默认设置通常没问题（需要调整 inode 数量的一个示例是邮件服务器，其中每封邮件都存储为单独的文件）。
作为一个快速而粗糙的监控解决方案，你可以有一个每分钟触发并运行一次的 cron 作业：
date >> /home/tmpfsspace
df -P /tmp >> /home/tmpfsspace
df -i /tmp >> /home/tmpfsspace
tail -n 7200 /home/tmpfsspace > /home/tmpfsspace
这样会为您留下一个文件，其中列出了过去 24 小时内 /tmp 文件系统上每天每分钟的可用空间和 inode，您可以使用该文件查看下次出现错误时 inode 空间是否是问题所在。该文件长度约为 425KB。这远远不够高效，因此不应将其用作永久解决方案，并且会遗漏由于文件太小而导致的问题，因为/tmp文件太小以至于一分钟内（检查的分辨率）就完全填满。您可以让脚本更复杂一些，date; du -shc /tmp/* > /home/tmpusewhennearfull如果 /tmp 上可用的空间或 inode 低于某个点（例如 50%），则运行该脚本，这样如果某些东西暂时占用了空间，您就有机会看到是什么占用了空间。
注意：我假设这是专用于您使用的服务器或虚拟机，如果您在共享服务器上，那么在安装监控软件等方面的选项就会受到很大限制。
答案2
耗尽 inode 也可能是问题所在。查看df -i/tmp 所在的分区是否接近 100%。