Крах баз при удалении большого числа сообщений

[Zadov]

Недавно перешел с Друпала на phpBB (хотя обычно переходят наоборот).
Причина перехода - форум Друпала не держит высокую нагрузку и и большое количество тем, и позорно загнулся, когда их количество еще даже не дошло до 1 млн.

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

Но недавно наткнулся на одну очень неприятную особенность. Понадобилось удалить все сообщения одного из пользователей форума, всего их оказалось около 2000 сообщений.
И вот тут phpBB заткнулся на целых 10 минут, впав в ступор, едва реагируя в это время на открытия страниц.
Но в итоге кое-как выплыл из этой ситуации, и снова бодро продолжил свою работу.

Затем, буквально вчера вечером понадобилось снова удалить сообщения другого пользователя, но их уже было побольше - около 24.000.

И вот тут-то phpBB упал на все 4 копыта, снова впав в ступор и никак не реагируя на внешние события.
Пришлось оставить его молотить на всю ночь, а когда утром проверил результаты удаления, оказалось, что ничего реально не удалилось, зато побились важные таблицы, и пришлось их восстанавливать из бекапа.

Это "фича" явилась крайне неприятной и опасной особенностью phpBB.
Нигде в описании на форум не нашел запрета, что нельзя удалять большое количество сообщений, а значит - можно.
Но реально, как оказалось, форум не в состоянии выполнять подобные задачи.
Дедик достаточно мощный, оперативки 8 Гиг, и на тормоза жаловаться не приходилось.
В обычном режиме phpBB на нем просто летает.

Значит, проблема удаления находится в самом phpBB. Как быть?

[Mr. Anderson]

Значит, проблема удаления находится в самом phpBB

Нет, это значит, что у вас MySQL не настроен на обработку больших массивов данных. Подозреваю, что настройки дефолтные, а это значит, что все буферы и кеши - мизерные.

Ну и, вероятно, php подтюнить надо - время выполнения скриптов, размер используемой памяти и тп.

[Zadov]

Так в том то и дело, что это не так - Мускулу в my.cnf выделено 128 Мб, php тоже дано памяти выше крыши.
Говорю же - phpBB летает на всех делах, кроме вот этого массового удаления.

Что же получается - phpBB просто не оптимизирован для такой операции - удаления большого числа сообщений?

Допустим, действительно для этих действий не хватало памяти. Тогда phpBB (если бы он был устроен по уму), обязан перевести их в Swap. Конечно, это сильно замедлило бы выполнение.
Но если бы и свопа не хватило (8 Гиг, кстати) - то почему движок не взял бы да и сказал по человечески - "Мне не хватает памяти, поэтому выполнять эту задачу не буду".
Но таблицы-то бить зачем??

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

Конечно, по большому счету не движок должен лезть в своп, это должен делать Linux по указанию движка.
Но не произошло ни того, ни другого - почему?

[Zadov]

Кстати, в процессе удаления образуется аж 140 процессов mysqld каждый VIRT 2604M и RES=487M, но оперативка 7798МБ занята не вся, свободных остается около 1500M.

[Mr. Anderson]

Мускулу в my.cnf выделено 128 Мб

На ЧТО выделено?

phpBB просто не оптимизирован для такой операции - удаления большого числа сообщений?

phpBB по барабану - он работает через драйвер БД.

Тогда phpBB (если бы он был устроен по уму), обязан перевести их в Swap

Серьезно? phpBB ничего не удаляет. Он дает команды, которые ВЫПОЛНЯЕТ СУБД.

даже не сделал попытки заглянуть в swap

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

Но не произошло ни того, ни другого - почему?

См выше. Главным образом потому, что вы придумываете несуществующие проблемы и механизмы.

в процессе удаления образуется аж 140 процессов mysqld

Ну после этого ни разу не удивительно, что все тупит, таблицы бьются, а итога нет. Это же к одним и тем же файлам ломятся сразу 140 процессов! Естественно никакого результата не будет.

Ну и так на секундочку, mysqld - это сервис, по дефолту сидящий на сокете... И я вообще не представляю, как он может "размножаться".

[Zadov]

Ну и так на секундочку, mysqld - это сервис, по дефолту сидящий на сокете... И я вообще не представляю, как он может "размножаться".

Я тоже не представляю. В обычном состоянии их всего 10.

Можете дать конкретные рекомендации (кроме чтения манов) по оптимизации системы для работы с высокой нагрузкой (включая удаления)?

[Mr. Anderson]

В обычном состоянии их всего 10.

Вот если бы в 10 раз меньше - я бы понял. А так - все равно больше одного... как-то да размножаются.

Можете дать конкретные рекомендации

Их не бывает. И уж тем более не вслепую.
Кто уж знает что у вас там за чудеса в настройках...

[Zadov]

Вот если бы в 10 раз меньше - я бы понял.

Понял, почему у нас по разному смотрится mysqld
Вы наверняка смотрите процессы обычным top, я же чаще htop, у него более расширенные варианты показа, и в данном случае, где top показывает один процесс, htop отображает 10, видимо, как форки от основного процесса.
Посмотрите сами, и наверное это лучше сможете объяснить, чем я.

[rxu]

Zadov
Каким инструментом удаляете? В управлении пользователями через админраздел?

Добавлено спустя 15 минут 19 секунд:
Можно попробовать следующее.

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

OPEN
includes/functions_admin.php

FIND
	foreach ($table_ary as $table)
	{
		$sql = "DELETE FROM $table
			WHERE " . $db->sql_in_set('post_id', $post_ids);
		$db->sql_query($sql);
	}

REPLACE WITH
	$sql = 'DELETE FROM ' . POSTS_TABLE . '
		WHERE ' . $where_clause;
	$db->sql_query($sql);

	$sql = 'DELETE FROM ' . REPORTS_TABLE . '
		WHERE ' . $db->sql_in_set('post_id', $post_ids);
	$db->sql_query($sql);

[Mr. Anderson]

Zadov
Часто у вас в htop ниже третьей-пятой строчки информация обновляется? Особенно в части TIME+
Подумайте над этим...

[Zadov]

Удаляю стандартным образом - "Пользователи и группы - Управление пользователями - Быстрые действия - Удалить все сообщения".

Пока придумал такой временный способ удаления большого числа сообщений выбранного пользователя:
1. Создаю вспомогательный форум "Для удаления сообщений".
2. Перемещаю в него удаляемые сообщения (это происходит очень быстро)
3. Использую функцию "Очистка форумовв", в котором есть такие параметры:
- Дней с последнего сообщения:
- Дней с последнего просмотра:
4. Уточняю, сколько лет прошло с регистрации пользователя на форуме (например, 5 лет)
5. Перевожу 5 лет в дни - 1825
6. В зависимости от числа удаляемых сообщений выбираю процент удаляемых за один заход, например, 5%,
что составляет 91 день.
7. Вычисляю разницу 1825 - 91 = 1733 дня
8. Подставляю это значение в "Дней с последнего сообщения" и "Дней с последнего просмотра".
9. Циклически очищаю сообщения до полного их удаления, всего приходится совершить таких 20 заходов.

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

Да, согласен, ужасно геморно, но что делать, если по другому пока никак не получается.

rxu, спасибо за скрипт, но если он никем всесторонне не проверен, воспользоваться им не рискну, слишком ответственный сайт.

Вообще-то хотелось докопаться до первопричины - почему phpBB так долго и фатально удаляет множество сообщений?

Вы тут подсказываете, что не оттюнен MySQL и PHP. Ну так подсказали бы, как его оттюнить, ведь на этом форуме, как понимаю, не одни новички собрались вроде меня.

[rxu]

если он никем всесторонне не проверен, воспользоваться им не рискну

Можно проверить на копии форума. Очевидно, для того, чтобы проверить его всесторонне, нужно а) длительное время, и б) аналогичная по объему пользовательская база (пользователей с 24 тыс. сообщениями найти не так просто, а генерировать такого - не менее муторно).

[Mr. Anderson]

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

Это невозможно сделать, не зная какие у вас УЖЕ есть настройки и какой у вас паттерн нагрузки.

[Zadov]

Пожалуйста, я готов выложить конфиги настроек, какие нужно?
И что понимается под паттерном нагрузки? Речь пока идет только о неудовлетворительной процедуре удаления большого числа сообщений одного пользователей.

О том, как phpBB держит высокую посещаемость, вопрос пока не стоит, и в его пользу могу сказать только одно - он держит ее в тысячу раз лучше, чем Друпальский "Advanced Forum", с которым провозился полгода, подбирая все мыслимые настройки LAMP, подключал сторонние механизмы кеширования, приглашал специалистов и т.п. - и все бестолку, тормоз есть тормоз.
Долго тестировал другие CMS и форумы, например, Amiro, который позиционируется "как самый быстрый CMS" - оказались враки, в основном хвалебные оды разработчиков о высоких скоростях своих творений оказались обычным лживым пиаром.
В итоге нашел быстроходный движок там, где совсем не ожидал - им оказался phpBB, с которым не работал уже лет так с 8.
И как только переехал на phpBB - все тормоза как рукой сняло (кроме удалений).
Конечно, при этом вместо портала (CMS) сайт превратился в обычный форум, но другого способа борьбы с тормозами найти не удалось.

Можно, конечно, было Друпал оставить как портал, а phpBB подключить нему как форум через мост. Но насколько понял, полной интеграции Друпала и phpBB при таком способе все равно не получится.

[Mr. Anderson]

И что понимается под паттерном нагрузки?

Какие стоят моды? Какая у вас посещаемость? В сутки, в среднем в час, сколько одновременно юзеров онлайн (обычно и в пиках). Какой хитрейт у вас? Какие боты к вам заходят? Есть ли настройка Crawl-delay в robots.txt? Какие наиболее популярные страницы (по хитам)?
От этого начнем плясать.