Я получаю следующее сообщение об ошибке на нашем веб-сервере в случайном случае:
Предупреждение: session_start (): open (/ tmp / sessions_7ifl201pvdd91rr6tr4015n5k4, O_RDWR) не удалось: на устройстве (28) не осталось места в /home/some/script/on/my/site/script.php в строке ##
Администратор моего сервера сообщает мне, что это должно быть что-то на сайте, которое вызывает это, например, кто-то загружает большой файл через PHP. Но я немного скептически настроен, так как это начало происходить только в последние пару дней.
Итак, мне было интересно, знает ли кто-нибудь еще о причинах, по которым это могло произойти? Я использую lightspeed (не apache), centos. Дайте мне знать, если потребуется дополнительная информация.
Если проблема заключается в больших загрузках от клиентов, вы можете немного смягчить ее, установив параметр LimitRequestBody (см. http://httpd.apache.org/docs/2.2/mod/core.html#LimitRequestBody - litespeed утверждает, что он совместим с Apache, поэтому он должен работать и там, если нет, вам нужно проверить их документы). Однако это ограничит только отдельные запросы - большое количество одновременных загрузок все еще потенциально может заполнить временное хранилище.
Насколько велик объем, который вмещает /tmp, и это специально для /tmp или поделился с другими областями? Было бы полезно добавить вывод df -h на ваш вопрос. Если у вас нет отдельной файловой системы для /tmp тогда что-то еще может заполнить объем.
Я бы посоветовал добавить на сервер мониторинг. я использую собирать следить за вещами и немного измененная версия этот сценарий для создания красивых изображений из записанных данных - есть несколько других популярных вариантов, которые также могут выполнять ту же работу. Вы можете попросить его контролировать используемое + свободное пространство файловой системы (используя этот модуль), то вы увидите, соответствуют ли ваши ошибки периоду, когда /tmp заполнен.
Файловая система может быть «полной», когда на ней достаточно места, если в ней заканчиваются inodes. В этом случае вы можете воссоздать файловую систему с большим их количеством. Обычно это проблема только тогда, когда у вас очень много маленьких файлов, поскольку значения по умолчанию при создании файловой системы обычно хороши (пример того, где количество inodes требует настройки, - это почтовые серверы, где каждое письмо хранится как отдельный файл).
В качестве быстрого и грязного решения для мониторинга у вас может быть задание cron, которое запускается каждую минуту и запускается:
date >> /home/tmpfsspace
df -P /tmp >> /home/tmpfsspace
df -i /tmp >> /home/tmpfsspace
tail -n 7200 /home/tmpfsspace > /home/tmpfsspace
В результате вы получите файл со списком свободного места и inodes в файловой системе / tmp в каждую минуту дня в течение последних 24 часов, который вы можете использовать, чтобы увидеть, является ли какое-либо пространство inodes проблемой, когда вы в следующий раз получите ошибку . Размер файла будет около 425 Кбайт. Это далеко не эффективно, поэтому не следует использовать его как постоянное решение, и в нем будут пропущены проблемы, вызванные /tmp просто быть слишком маленьким, чтобы он мог полностью заполниться за одну минуту (разрешение проверки). Вы можете сделать сценарий более красивым и запустить его date; du -shc /tmp/* > /home/tmpusewhennearfull если пространство или inode, доступные в / tmp, ниже определенной точки (например, 50%), тогда у вас есть шанс увидеть, что занимает пространство, если что-то временно.
Примечание. Я предполагаю, что это сервер или виртуальная машина, предназначенные для вашего использования. Если вы работаете на общем сервере, у вас гораздо более ограниченные возможности для установки программного обеспечения для мониторинга и т. Д.
Также проблемой может быть исчерпание inodes. смотреть на df -i и посмотрите, близок ли раздел, в котором находится / tmp, к 100%.