PHP - не удалось уничтожить объект сеанса
Я столкнулся со странной проблемой на Symfony: в основном иногда, без какой-либо очевидной причины, пользователь не может загружать веб-страницы, пока я не перезапущу php-fpm или пока он не изменит свой PHPSESSID, загрузив новый сеанс. В любом случае его сеанс все еще работает нормально после перезапуска fpm.
В то же время я получил 2 предупреждения от PHP:
PHP Warning: session_start(): Session object destruction failed in /home/unix/releases/1/vendor/symfony/symfony/src/Symfony/Component/HttpFoundation/Session/Storage/NativeSessionStorage.php on line 145
PHP Warning: session_start(): Failed to decode session object. Session has been destroyed in /home/unix/releases/1/vendor/symfony/symfony/src/Symfony/Component/HttpFoundation/Session/Storage/NativeSessionStorage.php on line 145
Учтите, что мы говорим о частном веб-сайте, который используется максимум 2-3 пользователями одновременно, но это также может произойти, если на нем просматривает только 1 пользователь.
Текущая настройка
- Debian 9.4 stretch 4.14.0-0.bpo.3-amd64
- php-fpm 7.1.15
- Symfony 3.4.4
Я могу воспроизвести проблему, используя apache ab, одновременно вызывая разные URL-адреса, используя один и тот же идентификатор сеанса. Конечно, после запросов N у меня был тайм-аут:
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
apr_pollset_poll: The timeout specified has expired (70007)
Total of 872 requests completed
Теперь я пытаюсь проверить конфигурацию php, но на самом деле это вполне «нормально» без специальных настроек, поэтому я не знаю, что мне попробовать или проверить. Есть предположения?
Спасибо за ваше предложение @Vyctorya - в настоящее время я сохраняю объекты в сеансе. Я думал то же самое, но до сих пор не могу понять, почему это происходит, например, после 872 запроса, а не напрямую по первому запросу ..
Может быть, вы достигли максимально допустимой переменной (stackoverflow.com/a/12916515/8411841) или максимального размера сеанса (stackoverflow.com/a/4649934/8411841)?
Эй, проверьте эту проблему - github.com/symfony/symfony/issues/18574
Также можно попробовать использовать PdoSessionHandler для хранения сеансов в базе данных
Также вы можете попробовать обновить свой PHP до актуальной стабильной версии - 7.2.x. Были похожие проблемы с 7.1.
А что у вас в session.auto_start в php.ini
И последний вопрос - а что насчет свободного дискового пространства?
Большое спасибо за ваши усилия. @Vyctorya обе вещи, о которых вы упомянули, похоже, не связаны с моей проблемой. @EugeneR session.auto_start отключен, на диске достаточно свободного места, эта проблема, похоже, связана с чем-то еще, а что касается сеансов в БД, я предпочитаю оставить ее как есть. В любом случае я попытаюсь обновить (или даже понизить) PHP.
Ответы 1
Проблема
Наконец я смог найти проблему. В основном это исходит от самой Symfony, поскольку по умолчанию кажется, что он также реализует своего рода логика сборки мусора в Symfony/Component/HttpFoundation/Session/Storage/Handler/StrictSessionHandler.php.
public function gc($maxlifetime)
{
return $this->handler->gc($maxlifetime);
}
Это не будет проблемой, если каталог /var/lib/php/sessions/ принадлежит тому же пользователю, указанному в php.ini, или если он имеет разрешения читать, но по умолчанию этот каталог принадлежит пользователю root и не доступен для чтения (поэтому файлы не могут быть перечислены). Это вызывает исключение, когда Symfony пытается вызвать сборщик мусора в обработчике текущего сеанса.
Решение
Есть два решения: установка
session:
gc_probability: ~
в Symfony config.yml или добавление разрешения читать в каталог сессий PHP (или, в конечном итоге, изменение относительного пользователя, используя то же, что определено в php.ini). Надеюсь, это может кому-то помочь.
Вы сохраняете сущности внутри сеанса? Однажды у меня была аналогичная проблема, когда сеанс стал слишком большим и больше не мог быть декодирован. Попробуйте сохранить идентификаторы вместо сущностей.