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

Проблемы с установкой или работой phpBB 3.2.x? Получите помощь здесь!
Правила форума
Местная Конституция | Шаблон запроса | Документация (phpBB3) | Мини [FAQ] по phpBB 3.1.x/3.2.x | FAQ | Как задавать вопросы | Как устанавливать расширения

Ваш вопрос может быть удален без объяснения причин, если на него есть ответы по приведённым ссылкам (а вы рискуете получить предупреждение ;) ).
Аватара пользователя
nissin
phpBB 3.0.4
Сообщения: 2180
Зарегистрирован: 16.12.2007 14:01
Откуда: Павлодар
Благодарил (а): 7 раз
Поблагодарили: 338 раз
Контактная информация:

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

Сообщение nissin » 03.11.2019 11:42

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

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

<!-- IF not S_IS_BOT -->{RUN_CRON_TASK}<!-- ENDIF -->
Всё повторяется. nurlan.info

Аватара пользователя
Siava
Поддержка
Поддержка
Сообщения: 4159
Зарегистрирован: 11.01.2005 14:29
Откуда: Питер
Благодарил (а): 109 раз
Поблагодарили: 435 раз
Контактная информация:

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

Сообщение Siava » 03.11.2019 12:01

nissin, автор темы использует системный крон каждые 5 минут... Эта строчка ведь для обычного, если я не ошибаюсь?
Еще одно нарушение правил и будете забанены. © Mr. Anderson
https://siava.ru/forum/ (phpbb 2.0.x, 3.1.x 3.2.x)

Andex
phpBB 1.4.1
Сообщения: 44
Зарегистрирован: 02.05.2006 11:51
Благодарил (а): 4 раза
Поблагодарили: 4 раза

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

Сообщение Andex » 03.11.2019 13:27

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

Аватара пользователя
rxu
phpBB Guru
phpBB Guru
Сообщения: 14475
Зарегистрирован: 12.05.2006 18:16
Откуда: Красноярск
Благодарил (а): 346 раз
Поблагодарили: 1544 раза
Контактная информация:

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

Сообщение rxu » 03.11.2019 16:38

Изображение

Andex
phpBB 1.4.1
Сообщения: 44
Зарегистрирован: 02.05.2006 11:51
Благодарил (а): 4 раза
Поблагодарили: 4 раза

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

Сообщение Andex » 03.11.2019 17:00

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

Аватара пользователя
nissin
phpBB 3.0.4
Сообщения: 2180
Зарегистрирован: 16.12.2007 14:01
Откуда: Павлодар
Благодарил (а): 7 раз
Поблагодарили: 338 раз
Контактная информация:

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

Сообщение nissin » 03.11.2019 20:57

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

Andex
phpBB 1.4.1
Сообщения: 44
Зарегистрирован: 02.05.2006 11:51
Благодарил (а): 4 раза
Поблагодарили: 4 раза

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

Сообщение Andex » 04.11.2019 20:08

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

Как я говорил в самом начале, 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
А если так
Пока не добрался, постараюсь завтра

Аватара пользователя
rxu
phpBB Guru
phpBB Guru
Сообщения: 14475
Зарегистрирован: 12.05.2006 18:16
Откуда: Красноярск
Благодарил (а): 346 раз
Поблагодарили: 1544 раза
Контактная информация:

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

Сообщение rxu » 04.11.2019 21:20

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

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

Аватара пользователя
rxu
phpBB Guru
phpBB Guru
Сообщения: 14475
Зарегистрирован: 12.05.2006 18:16
Откуда: Красноярск
Благодарил (а): 346 раз
Поблагодарили: 1544 раза
Контактная информация:

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

Сообщение rxu » 05.11.2019 6:38

Andex, а какой у вас форум, если не секрет.
Изображение

Andex
phpBB 1.4.1
Сообщения: 44
Зарегистрирован: 02.05.2006 11:51
Благодарил (а): 4 раза
Поблагодарили: 4 раза

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

Сообщение Andex » 05.11.2019 23:18

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
а какой у вас форум, если не секрет.

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

Аватара пользователя
rxu
phpBB Guru
phpBB Guru
Сообщения: 14475
Зарегистрирован: 12.05.2006 18:16
Откуда: Красноярск
Благодарил (а): 346 раз
Поблагодарили: 1544 раза
Контактная информация:

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

Сообщение rxu » 06.11.2019 5:14

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

Ответить

Вернуться в «Поддержка phpBB 3.2.x»