Страница 2 из 2

Re: Большие таблицы sessions, sessions_keys, confirm и login_attempts - что не так с session_gc()

Добавлено: 03.11.2019 11:42
nissin
Andex писал(а): 01.11.2019 19:13 Крон этот, как я уже и говорил, у меня выполняется каждые 5 минут, но за 5 минут успевают нагенерить сессий больше, чем потом удаляется. И через несколько лет мы имеем описанную мной картину...
Посмотрел код ещё раз.
Очистка сессий должна выполнятся до тех пор пока не закончит очистку полностью.
Без всяких перерывов ни на 5, ни даже на 1 минуту. Одно закончилось, другое началось.
Думаю, что у вас задания cron не исполняются по какой-то причине.
Случайно в шаблоне overall_footer.html не выпилили строчку:

Код: Выделить всё

<!-- IF not S_IS_BOT -->{RUN_CRON_TASK}<!-- ENDIF -->

Re: Большие таблицы sessions, sessions_keys, confirm и login_attempts - что не так с session_gc()

Добавлено: 03.11.2019 12:01
Siava
nissin, автор темы использует системный крон каждые 5 минут... Эта строчка ведь для обычного, если я не ошибаюсь?

Re: Большие таблицы sessions, sessions_keys, confirm и login_attempts - что не так с session_gc()

Добавлено: 03.11.2019 13:27
Andex
Все верно, крон системный, юниксовый, а не псевдокрон внутри самого движка phpbb, дергающийся во время генерации страниц.
Собтсвенно, по большому счету проблема решена, узкие места указаны.

Re: Большие таблицы sessions, sessions_keys, confirm и login_attempts - что не так с session_gc()

Добавлено: 03.11.2019 16:38
rxu

Re: Большие таблицы sessions, sessions_keys, confirm и login_attempts - что не так с session_gc()

Добавлено: 03.11.2019 17:00
Andex
rxu, надо вникнуть... попробую ко вторнику на своей БД погонять. Отпишусь

Re: Большие таблицы sessions, sessions_keys, confirm и login_attempts - что не так с session_gc()

Добавлено: 03.11.2019 20:57
nissin
Andex писал(а): 03.11.2019 13:27 Все верно, крон системный, юниксовый, а не псевдокрон внутри самого движка phpbb, дергающийся во время генерации страниц.
В таком случае прошу прощения, неправильно понял.

Re: Большие таблицы sessions, sessions_keys, confirm и login_attempts - что не так с session_gc()

Добавлено: 04.11.2019 20:08
Andex
В общем, еще немного расследований и пожеланий к улучшению.

Как я говорил в самом начале, session_gc() также чистит и таблицу confirm, в которую записи добавляются при каждом дерганье Гостем posting.php.
После того как сессии успешно почистились, успешно почистилась и табличка confirm — вместо 4,5 млн записей осталось 220 тысяч.
И эти 220 тыс. как-то не уменьшаются... Решил я посмотреть, что там внутри, и оказалось, что все сгенеренные капчи (кроме 5-7 штук) — принадлежат одной сессии! Т.е. 220 тыщ капч для одной сессии (а значит, она живая).

Решил посомтреть, что это за сессия, и оказалось, что с 22 октября под этой сессией ходит нечто
IP: 54.144.21.1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/600.2.5 (KHTML, like Gecko) Version/8.0.2 Safari/600.2.5 (Amazonbot/0.1; +https://develop

Какой-то амазоновый бот, причем вроде не просто кто-то развернул какой-то граббер, а вроде реально что-то амазоновое (но не уверен) - может кто знает что это?
https://developer.amazon.com/support/amazonbot


Ну и собсно время от времени он натыкается на постинг и нагенерил за две недели уже 220 тыщ капч :)

Можно было бы втупую заблочить его по IP или User-Agent, но я все же решил плюнуть на него и посомтреть, почему генерится капча для Гостей.

Прежде всего
Siava писал(а): 01.11.2019 20:03 В настройках безопасности есть такая строка, "привязать формы к гостевым сессиям" или что-то в таком духе. Быть может её использование генерит кучу confirm?
Так, пальцем в небо тычу..
Не, не оно


Глянул код posting.php

Там почти в самом начале процесса встречаем (в районе 259 строки)

Код: Выделить всё

if ($config['enable_post_confirm'] && !$user->data['is_registered'])
{
	$captcha = $phpbb_container->get('captcha.factory')->get_instance($config['captcha_plugin']);
	$captcha->init(CONFIRM_POST);
}
До этого никаких проверок нет - вот мы и получили еще одну капчу в таблице confirm.

Чтобы этого избежать, достаточно изменить в настройках форума:
Использовать средства против спам-ботов при отправке сообщений гостями:
(Enable spambot countermeasures for guest postings:)
Поскольку Гостям в принципе не разрешается что-либо постить, то отключение этой штуки решает проблему с добавлением таких капч.


Если же копнуть в сам код и предложить улучшения — все просто, нужно этту генерацию капчи перенести пониже, наверно после опеределения переменной $is_authed (где-то так в районе экстеншена @event core.modify_posting_auth)

Как считатете?

Да, ну и этого Amazonbot тоже можно в список ботов добавить...


PS. А еще у меня есть проблемка с удалением пользователей - там тоже используется пара "нелучших" запросов, с которыми при большой БД практически исчезает возможность удаления даже единичного пользователя, не говоря уже о пачке за раз - если позволите, под этой случай создам все же отдельный топик. Может тоже какие усовершенствования добавятся в 3.3...

rxu писал(а): 03.11.2019 16:38А если так
Пока не добрался, постараюсь завтра

Re: Большие таблицы sessions, sessions_keys, confirm и login_attempts - что не так с session_gc()

Добавлено: 04.11.2019 21:20
rxu
Andex писал(а): 04.11.2019 20:08Как считатете?
Надо посмотреть, если каптчи генерятся тысячами зазря - то конечно.

Отправлено спустя 25 минут 29 секунд:
https://github.com/phpbb/phpbb/pull/5729

Re: Большие таблицы sessions, sessions_keys, confirm и login_attempts - что не так с session_gc()

Добавлено: 05.11.2019 6:38
rxu
Andex, а какой у вас форум, если не секрет.

Re: Большие таблицы sessions, sessions_keys, confirm и login_attempts - что не так с session_gc()

Добавлено: 05.11.2019 23:18
Andex
rxu писал(а): 03.11.2019 16:38 А если так
https://github.com/phpbb/phpbb/pull/5728/files
Хм... Не припомню, чтобы раньше встречался с UPDATE, в котором несколько таблиц и еще и данные подставлять из одной в другую... Еще и временная таблица... Изящно! :?

Что обнаружил при тестах на своей БД (до чистки) - если выполнить $sql_select получим 15437 строк.
Если выполнить внутренний подзапрос, который иннерджойнится - 15416 строк — получается, что у некоторых пользователей есть несколько сессий с одним и тем же session_time - посмотрел и правда, есть с десяток такого... как оно получилось ума не приложу - может это как раз "отсылочка" к вопросу о разлогиниваниях из соседнего топика.

А далее, выполнив UPDATE - получил 15409 затронутых строк... Ну можно допустить, что за эти годы какие-то пользователи были удалены, а непочищенные сессии пооставались.

Поэтому, в целом, считаю ваше решение рабочим и хорошим :hat
Выполняется все довольно быстро, до секунды на моей локальной виндовой не шибко быстрой системе. В районе 0,7-0,8 секунды занял этот апдейт с вложенными селектами.


Там же $this->time_now не меняет значение по ходу выполнения скрипта?


rxu писал(а): 05.11.2019 6:38 а какой у вас форум, если не секрет.

Секрет, но в личку отпишу конечно)

Re: Большие таблицы sessions, sessions_keys, confirm и login_attempts - что не так с session_gc()

Добавлено: 06.11.2019 5:14
rxu
Andex писал(а): 05.11.2019 23:18 Там же $this->time_now не меняет значение по ходу выполнения скрипта?
Нет, только при каждом новом запуске скрипта.

Re: Большие таблицы sessions, sessions_keys, confirm и login_attempts - что не так с session_gc()

Добавлено: 16.12.2019 15:25
rxu
Фикс #5728 с очисткой таблицы сессий выйдет в версии 3.3-RС1.

Re: Большие таблицы sessions, sessions_keys, confirm и login_attempts - что не так с session_gc()

Добавлено: 03.04.2020 11:06
Old Human
Прошу прощения за некромантию :oops: , но обнаружил также таблицу sessions размером 700мб и хочу уточнить, решен ли вопрос в 3.3 с очисткой сессий?

Re: Большие таблицы sessions, sessions_keys, confirm и login_attempts - что не так с session_gc()

Добавлено: 03.04.2020 11:08
rxu
Old Human писал(а): 03.04.2020 11:06 решен ли вопрос в 3.3 с очисткой сессий
Решен.