С некоторых пор, пор перестала очищаться таблица сессий _session - страница 2 - Joomla 3.x: Общие вопросы

Проверил. Очистил таблицу сессий, зашел как один пользователь с фронта - 4 записи одинаковые с разным таймом (никто не мог туда войти сайт на локалхосте)



что за хрень с сессиями в последних версиях не понимаю, на версиях PHP 5/6-7/0 все одинаково

сразу видно ISP Manager

Сразу видно Debian. Ну это надо знать.

Правильно ли я понял отсюда, что есть такое решение сейчас, если сессии хранятся в БД https://github.com/joomla/joomla-cms/issues/19146?

1. Меняем libraries/src/Application/CMSApplication.php на этот https://github.com/joomla/joomla-cms/pull/19165/files
2. Выставляем session.gc_probability в 0.
3. Запускаем cron-ом session_gc(). (PHP 7 >= 7.1.0).

помимо gc_probability есть еще gc_divisor и gc_maxlifetime. ну и подождать же надо, они не прям мгновенно удалятся.

Да, - не сразу...
Сейчас таблица  _session, больше 10 МБ не растет, т.е session.gc_probability=1 работает. На шареде, там у хостера по умолчанию session.gc_probability=1 и _session, около 6 МБ (меньше посещаемость сайта).

т.е session.gc_probability=1 работает

Я ставил php 7 из исходников для CentOS. По умолчанию стоят:

session.gc_divisor   1000
session.gc_maxlifetime   1440
session.gc_probability   1

В этом случае сам php 7 управляет очисткой сессий, насколько я понимаю.

Суть подхода в моем предыдущем посте, на мой взгляд, заключается в том, чтобы отключить этот параметр, и самому контролировать процесс. В cron при этом ставится принудительная очистка, вызовом скрипта с session_gc(), используя обработчик рhp (CLI), а не через веб (?). [GC кстати означает Garbage Collection (Уборка мусора)]

Похоже, что эта проблема характерна для сайтов с большим количеством посещений, и задумка разработчиков в том, чтобы разгрузить MySQL в отношении очистки таблицы сессий, используя возможности php 7 для управления сессиями, а не запросы MySQL для очистки этой таблицы. Также, возможно, что у некоторых хостеров по умолчанию session.gc_probability 0. Тогда, конечно, будет труба для таких сайтов.

Итого, все OK, так как этот пулл прошел несколько проверок и пойдет в J 4. Жизнь налаживается 

PS. Даже если использовать обработчик сессий НЕ база данных, все равно таблица сессий будет заполняться. Или нет?

Суть подхода в моем предыдущем посте, на мой взгляд, заключается в том, чтобы отключить этот параметр, и самому контролировать процесс.

точно, именно в этом. только не очень ясно с какой целью это делать если работу можно переложить на нативный сборщик мусора то зачем это делать руками или по крону нагружая php - ума не приложу

Может потому, что у некоторых хостеров он 0, и изменить его юзверям нельзя...

а, ну это да. в такой ситуации ясное дело, только так. правда хостеру написать можно, по сути это и ему надо тоже, а то место ж на диске тоже не резиновое под сессии...

Хостеру плевать на место, если у нас в рамках аккаунта выделенное место кончилось он отключит аккаунт.
Недавно было такое с битриксом, который под бекапы кушал по 4 гига, теперь вот сессии Joomla. Каждый чих блин нужно контролировать

не думаю что сессии кушают место в аккаунте. разве есть хостеры у которых сессии хранятся в домашнем каталоге юзера?

не думаю что сессии кушают место в аккаунте. разве есть хостеры у которых сессии хранятся в домашнем каталоге юзера?

почему нет? Любая таблица это объем БД, БД хранится на акке юзверя, если превышает - будут предупреждения и блокировки

речь о нативных сессиях php. файлах.

речь о нативных сессиях php. файлах.

А, это я не в курсе, надо уточнять у каждого хостера. Привык что сессии в базе хранятся. Кстати решение с директивой помогло, 8000 левых записей в сесии уменьшилось до реальных 300.
Это вообще баг последней 3.8.5 версии?

та ну не баг же перешли на нативные сессии php. вернее, не перешли, а ориентируются по ним, устарела сессия Joomla или нет. чтоб не гонять запросами базу постоянно, проверять. запросы достаточно тяжелые, разгрузили базу. но вот вылезло что у некоторых gc_probability =0 и файловые сессии вообще не чистятся нативным сборщиком мусора. ну а вместе с ними соответственно и сессии Joomla которые в базе тоже не чистятся.

Скажем так вылезло у всех почти
В чем проблема дергать базу (если там не 5 тыщ уников ежесекундно) не вижу
у кого нагруженные сайты сами все контролируют, а так получилось что у хомяков с 50-1000 даже не уников в день база растет в десятки раз от нормы....

В чем проблема дергать базу (если там не 5 тыщ уников ежесекундно) не вижу

достаточно тяжелый запрос. который выполнялся каждый раз при вообще любом просмотре. я откровенно говоря вообще не вижу смысла сессии держать в базе.

достаточно тяжелый запрос. который выполнялся каждый раз при вообще любом просмотре. я откровенно говоря вообще не вижу смысла сессии держать в базе.

тяжелый запрос на delete при известном timestamp? Да ну
Просто нужно граничить мелкие и большие сайты и нельзя их ровнять
А тут получилось что разработчики решили за нас и мы получили по 5 тыщ записей в таблице сессий в день при 200 уников на сайте и это число растет и не чистится, хотя время сессии установлено

да короче гемор подогнали под конец жизненного цикла тройки.
вот нафига все эти мерджи с 4-ой такими телодвижениями?
вместо единовременного гемора с переездом получам в каждом обновлении по кусочку. такое ощущение, что у них план развития писали после... принятия плана внутрь 
короче, для мелкосайтов хороший дядя Viktor Vogel написал плагин:
https://joomla-extensions.kubik-rubik.de/downloads/esk-easy-session-killer/joomla-3

но вот вылезло что у некоторых gc_probability =0

А вывести сообщение при обновлении прямо нельзя было. Есть даже механизм для этого.
Плюс при установке проверять и выводить предупреждение.

тяжелый запрос на delete при известном timestamp?

да. занимал в некоторых случаях до 25% всего времени запросов. запросы обновления таблицы всегда тяжелые.

А вывести сообщение при обновлении прямо нельзя было.

это не ко мне нужно было конечно. собственно, они ж уже признали что решение далеко от идеального и будут его дорабатывать.

ESK - Easy Session Killer

Я вот этого не понял

To reduce the server load and increase the performance, the probability how often the plugin should check the database for expired sessions can be set manually. The plugin is only triggered in the front end!

Можно запускать вручную, или запускается только вручную ?
Если вручную, то как его запускать?

ESK - Easy Session Killer
Можно запускать вручную, или запускается только вручную ?
Если вручную, то как его запускать?

Да нет, судя по описанию плагин отрабатывает при любой работе на фронте, чистит сессии, код не смотрел.

Можно запускать вручную, или запускается только вручную ?

не запускать, а задать как часто проверять. я так понимаю в настройках плагина есть параметр интервала проверки, который следует понимать как Проверять истекшие сессии не раньше чем через ... минут после последней проверки, например

Если вручную, то как его запускать?

Он по будет чистить каждые N посещений, как я понял. Ставь 50 или 100 и норм должно быть.

Он по будет чистить каждые N посещений, как я понял. Ставь 50 или 100 и норм должно быть.

ставь 1000 не ошибешься)

плагин Disqus (комментарии к статьям) начал выдавать ошибку на страницах меток. Пришлось встраивать HTML код вручную вместо использования плагина

это как то относится к неочищению таблицы сессий? или вы просто топик перепутали?

Прилепите решение этой проблемы либо в шапку ветки или в шапку темы и тоже прикрепите.
Меня за неделю порядка 10 клиентов, что обновились просто вытрахали мозг (хоть и не нанимался поддерживать их сайты но без ответа оставить не мог).
В общем какое то закрепление решения должно быть.

Прилепите решение этой проблемы либо в шапку ветки или в шапку темы и тоже прикрепите.
Меня за неделю порядка 10 клиентов, что обновились просто вытрахали мозг (хоть и не нанимался поддерживать их сайты но без ответа оставить не мог).
В общем какое то закрепление решения должно быть.

Написал 3 решения в первом топике,

а вот когда я написал на Релиз Joomla 3.8.5 отзыв про результат обновления и ссылку на эту тему, его проигнорировали и не опубликовали