我在我们的Web服务器上偶尔遇到以下错误：
警告：session_start（）：打开（/ tmp / sess_7ifl201pvdd91rr6tr4015n5k4，O_RDWR）失败：设备上没有剩余空间（28）/home/some/script/on/my/site/script.php在线##
我的服务器pipe理员告诉我，它必须是在网站上造成这种情况，如有人通过PHP上传一个大文件。 但我有点怀疑，因为这只是在过去几天才开始发生的。
所以，我想知道是否有人知道为什么会出现这种情况？ 我正在运行光速（不是apache），centos。 让我知道是否有任何更多的信息需要。
如果问题是来自客户端的大量上传，可以通过设置LimitRequestBody选项来缓解这个问题（请参阅http://httpd.apache.org/docs/2.2/mod/core.html#LimitRequestBody – litespeed声明为drop-与Apache兼容，所以它也应该在那里工作，如果没有，你需要检查他们的文档）。 这只会限制单个请求 – 同时大量的上传仍然可能会填满临时存储。
容纳/tmp的音量有多大，是专门用于/tmp还是与其他区域共享？ 将df -h的输出添加到您的问题将会很有帮助。 如果你没有一个独立的/tmp文件系统，那么其他地方的东西就会填满这个卷。
我会build议添加一些监控到服务器。 我使用collectd来关注事物，并且稍微改变了这个脚本的版本，以便从logging的数据中产生漂亮的图片 – 还有一些其他stream行的选项也可以完成同样的工作。 你可以让它监视文件系统空间使用+免费（使用这个模块 ），那么你会看到，如果你的错误对应于/tmp填充期间。
如果文件系统耗尽了inode，那么当文件系统空间充足时，文件系统可能会“满”。 如果是这种情况，那么你可以用更多的文件系统重新创build文件系统。 当创build一个文件系统的默认值很多时，这通常只是一个问题。（inode数量需要调整的例子是邮件服务器，每个邮件存储为一个单独的文件）。
作为一个快速和肮脏的监控解决scheme，您可以有一个cron作业，每分钟都会启动并运行：
date >> /home/tmpfsspace df -P /tmp >> /home/tmpfsspace df -i /tmp >> /home/tmpfsspace tail -n 7200 /home/tmpfsspace > /home/tmpfsspace
这将为您留下一个文件，其中列出了空间和inode在/ tmp文件系统上的最近24小时的每一分钟的空闲时间，您可以使用这些文件查看inode的空间是否是下一次出现错误时的问题。 该文件将是大约425千字节长。 这是远远没有效率的，所以不应该作为一个永久性的解决scheme，并会错过由/tmp造成的问题，因为它太小了，因此它可以完全填满一分钟（检查的结果）。 你可以使脚本更花哨，并有它的运行date; du -shc /tmp/* > /home/tmpusewhennearfull date; du -shc /tmp/* > /home/tmpusewhennearfull如果/ tmp上的可用空间或inode低于某个特定点（例如50％），那么如果暂时有东西可以看到正在消耗空间的东西。
注意：我假设这是一个服务器或虚拟机专用于您的使用，如果你在一个共享的服务器上，那么你有更多有限的选项安装监视软件等等。
用完inode也可能是问题。 看看df -i ，看看/ tmp所在的分区是否接近100％。