Очистка старых сессий в MODX

Есть давнишний вопрос про большую таблицу modx_session, лично у меня она занимает 1.1 гигабайт и содержит около 500 000 записей. С одной стороны - не напрягает, а с другой непонятно, почему она понемногу растёт?

Таблица состоит из 3х колонок: идентификатор, время изменения и собственно данные сессии. У меня самая старая сессия от 30 октября 2013 года, то есть менялась она 3 месяца назад.

В настройках же установлена session_gc_maxlifetime = 604800, то есть старые сессии должны удаляться через 7 дней. По умолчанию, все сессии хранятся в БД, значит настройки хостинга и ~~стандартный сборщик мусора тут не помогут - это должен делать сам MODX~~. Поправка - см. обновление в конце заметки.

Я полез искать, а где собственно у MODX сборщик старых сессий? Он нашелся в классе modSessionHandler - которая и рулит сессиями по умолчанию.

/**
* Remove any expired sessions.
*/
public function gc($max) {
    $maxtime= time() - $this->gcMaxLifetime;
    $result = $this->modx->removeCollection('modSession', array("{$this->modx->escape('access')} < {$maxtime}"));
    return $result;
}

Во-первых, здесь неиспользуемый аргумент $max. А во-вторых, этот метод не вызывается в коде MODX, вообще.

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

Как же нам почистить старые сессии? Очень просто:

$session = new modSessionHandler($modx);
$session->gc();

Метод использует modX::getCollection(), поэтому в первый раз скрипт будет выполняться ооочень долго и может даже выпасть по таймауту.

Теперь осталось дождаться ответа от авторов MODX, почему метод modSessionHandler::gc() не используется.

Jason Coward говорит, что PHP сам вызывает этот метод, без MODX. Звучит логично, и проблема, наверное, в дефолтных настройках моей Ubuntu - там session.gc_probability = 0.

То есть, стандартный сборщик никогда не запусается и ОС чистит сессии своим скриптом по cron. Понятно, что консольный скрипт ничего не знает ни про modSessionHandler, ни про другие нестандартные способы хранения сессий. Но непонятно. зачем так сделано? На багтрекере Ubuntu этот вопрос повис аж с 2009 года.

Поставил session.gc_probability = 1, а session.gc_divisor = 10, теперь сессии должны очищаться в 10% новых стартов. ~~Пока изменений нет, буду наблюдать~~. Всё почистилось, переставил divisor на 100.

Проверять возраст сессий можно в phpMyAdmin:

SELECT id, FROM_UNIXTIME(access) as access FROM `modx_session` 
    ORDER BY access ASC LIMIT 10

Будет вот так:

В общем, владельцы Ubuntu, заходите в /etc/php5/fpm/php.ini и меняйте session.gc_probability на 1. Divisor можно оставить на 1000 или поменять на 100 - зависит от посещаемости сайта. Чем больше ходит народу, тем больше должен быть session.gc_divisor.

Сам механизм расширения сессий описан в документации, и действительно, PHP запускает всё самостоятельно - поэтому в коде MODX нет вызова ни одного из методов modSessionHandler.

Судя по количеству вопросов в поисковиках про большую modx_session - много кто использует хостинги с отключенной сборкой старых сессий. Вроде как, даже на http://modx.com такая проблема:

Значит, не зря я тут волну поднял.

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

13 комментариев

Сергей Шлоков

Отличное исследование. Периодически задавался вопросом, почему сессии не чистятся. Особенно заметно, когда переносишь базу. Такое полотенце. Напиши когда ответят.

Василий Наумкин

Уже, смотри обновление.

Всё выходит еще интереснее - похоже виноваты стандартные настройки моей ОС.

Чикин Артур

Я то думаю почему сегодня раза 3-4 на безумкин надо было авторизироваться)

Василий Наумкин

Это я еще заодно проверил, есть ли смысл перейти на обычные файловые сессии?

Нет, нету.

Чикин Артур

Обновлено 06.12.2014 Что то с датами?

Василий Наумкин

Нет, в датами всё нормально - у меня часовой пояс Новосибирска и новые дни наступают немного раньше, чем в столицах.

Дошло, что месяц неверный - поправил.

Чикин Артур

Я из Абакана. У меня еще раньше чем в Новосибирске:)

Виталий Киреев

А session.gc_maxlifetime в php.ini должен быть, как в настройках MODX или тут он не влияет? У меня сейчас стоит 1440 секунд.

Василий Наумкин

Настройка MODX выставляет свою lifetime. Просто смотри Отчеты → Информация о системе → phpinfo() из админки, и будет ясно, какие параметры используются.

Виталий Киреев

А вообще у SessionHandler class написано PHP 5 >= 5.4.0, т.е. на более ранних версиях этот код все же совсем не используется? А у MODX заявлена поддержка от 5.2.0.

Василий Наумкин

Я так понимаю, это документация актуальна с версии 5.0 по 5.4.

Функция session_set_save_handler работает вообще с PHP 4.

Igor Ostancov

Сорри промахнулся веткой... Может добавить возможность удалять комментарии? ))

Василий Наумкин

Эта возможность есть - у меня.