VBsupport перешел с домена .ORG на родной .RU
Ура!
Пожалуйста, обновите свои закладки - VBsupport.ru
Блок РКН снят, форум доступен на всей территории России, включая новые терртории, без VPN
На форуме введена премодерация ВСЕХ новых пользователей
Почта с временных сервисов, типа mailinator.com, gawab.com и/или прочих, которые предоставляют временный почтовый ящик без регистрации и/или почтовый ящик для рассылки спама, отслеживается и блокируется, а так же заносится в спам-блок форума, аккаунты удаляются
Если вы хотите приобрести какой то скрипт/продукт/хак из каталогов перечисленных ниже: Каталог модулей/хаков
Ещё раз обращаем Ваше внимание: всё, что Вы скачиваете и устанавливаете на свой форум, Вы устанавливаете исключительно на свой страх и риск.
Сообщество vBSupport'а физически не в состоянии проверять все стили, хаки и нули, выкладываемые пользователями.
Помните: безопасность Вашего проекта - Ваша забота. Убедительная просьба: при обнаружении уязвимостей или сомнительных кодов обязательно отписывайтесь в теме хака/стиля
Спасибо за понимание
Доброго всем времени суток и праздничного настроения!
Как обычно, не прошло и 16 миллиардов лет, как моя скромная персона снова взывает к помощи великих мастеров укрощаемого форумного движка.
Имеется 3.8.1 лицензия. Одновременно сидящих пользователей, включая "гостей", обычно около 1500. Сервер - не сказал бы, что тухлый: 16 гектар для памяти, SAS 250 в зеркале на LSI Logic, 4 аппаратных проца, самцы (двухъядерные).
Мускль 5.0.95, пых 5.3.х.
Часть таблиц сконвертирована в InnoDB (в которых нет необходимости организовывать полнотекстовый индекс), часть, например, vb3_post и vb3_thread - в myISAM.
И так всё лабало порядка трёх лет: аптайма на сервере по состоянию на позавчера было 890 дней. Вдруг начались тормоза. В системе начали плодиться процессы апача, причём особо не отнимая ни процессорное время, ни память, а в мускле толпилась очередь из запросов. Протоколирование "длинных" запросов показало, что практически все запросы мускль исполняет как "длинные".
Например, запрос
PHP Code:
pmtext.pmtextid FROM vb3_pmtext AS pmtext LEFT JOIN vb3_pm AS pm USING(pmtextid) WHERE pm.pmid IS NULL
стоял в очереди около 700 секунд.
Просмотр общего состояния системы говорит, что дисковая подсистема загружена на 100%, а операций ввода/вывода исполняется чуть больше 200/сек, что очень мало.
Обращение напрямую к рэйд-контроллеру и дискам через рэйд-утилиту на предмет просмотра статуса задач показывает, что текущих задач по контроллеру и по дискам нет.
"Тормоза" могут длиться как час, так и полдня. Потом опять же "внезапно" очередь запросов начинает разгребаться, "ожидающие ответа" процессы апача умирать своей смертью, мускль начинает шустро отдавать данные, по дисковой подсистеме производительность становится 3500+транзакций/сек и форум начинает летать.
В общем, ситуация для меня не совсем ясная.
Планирую сейчас смигрировать на Mysql 5.6 и сконвертить оставшиеся таблицы в InnoDB. Сейчас этого сделать нельзя, т.к. текущая версия мускля не поддерживает полнотекстовый индекс, а начиная с 5.6 InnoDB уже умеет это делать.
Буду рад любым советам. Спасибо.
Всем добра, чистой кармы и хороших финансовых вливаний!
Запрос, который указан в примере это из includes/cron/cleanup2.php
Code:
// Orphaned pmtext records are removed after one hour.
// When we delete PMs we only delete the pm record, leaving
// the pmtext record alone for this script to clean up
$pmtexts = $vbulletin->db->query_read("
SELECT pmtext.pmtextid
FROM " . TABLE_PREFIX . "pmtext AS pmtext
LEFT JOIN " . TABLE_PREFIX . "pm AS pm USING(pmtextid)
WHERE pm.pmid IS NULL
");
Бардак с личками?
Выполните запрос в phpMyAdmin
Code:
EXPLAIN SELECT pmtext.pmtextid FROM vb3_pmtext AS pmtext
LEFT JOIN vb3_pm AS pm USING(pmtextid) WHERE pm.pmid IS NULL;
@tarasus
Простоузер
Join Date: Jan 2010
Location: N-Novgorod
Posts: 50
Версия vB: 3.8.x
Пол:
Reputation:
Опытный 18
Репутация в разделе: 9
2
Это первая попавшаяся строка из mtop - утилиты, просматривающей процессы, творящиеся в мускле; из пятисот запросов, стоящих в очереди, можно было бы выбрать любой другой, просто этот покороче и помещается на длину экрана Да и смущает как раз то, что он вроде бы короткий, а выполняется так долго.
С личками вроде бы всё в порядке.
Прогнал сейчас дополнительно через админку оптимизацию/восстановление баз. Некоторые ошибки были обнаружены, хотя та же самая процедура, но средствами мускля, говорила ok.
Посмотрим, как дальше будет жить.
tarasus добавил 07.05.2015 в 11:11
Quote:
Originally Posted by hoo
Бардак с личками?
Выполните запрос в phpMyAdmin
Code:
EXPLAIN SELECT pmtext.pmtextid FROM vb3_pmtext AS pmtext
LEFT JOIN vb3_pm AS pm USING(pmtextid) WHERE pm.pmid IS NULL;
Code:
mysql> EXPLAIN SELECT pmtext.pmtextid FROM vb3_pmtext AS pmtext LEFT JOIN vb3_pm AS pm USING(pmtextid) WHERE pm.pmid IS NULL;
+----+-------------+--------+-------+---------------+----------+---------+-------------------------+--------+--------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+--------+-------+---------------+----------+---------+-------------------------+--------+--------------------------------------+
| 1 | SIMPLE | pmtext | index | NULL | PRIMARY | 4 | NULL | 501957 | Using index |
| 1 | SIMPLE | pm | ref | pmtextid | pmtextid | 4 | pr_last.pmtext.pmtextid | 1 | Using where; Using index; Not exists |
+----+-------------+--------+-------+---------------+----------+---------+-------------------------+--------+--------------------------------------+
2 rows in set (0.21 sec)
Code:
load averages: 1.83, 3.85, 4.71 mysqld 5.0.95-log up 2 day(s), 12:50 hrs
510 threads: 509 running, 0 cached. Queries/slow: 829/2 Cache Hit: 99.65%
Opened tables: 0 RRN: 91.4K TLW: 2.9K SFJ: 0 SMP: 0 QPS: 0
ID USER HOST DB TIME COMMAND STATE INFO
1135964 dbuser localhost userdb 726 Query Sending data SELECT pmtext.pmtextid FROM vb3_pmtext AS pmtext LEFT JOIN vb3_pm AS pm USING(pmtextid) WHERE pm.pmid IS NULL
tarasus добавил 08.05.2015 в 10:45
В развитие темы и в качестве отчёта.
Систему обновили до крайнего релиза в линейке.
Мускль - 5.6.
Пых - 5.4
Конверт таблиц в InnoDB, построение полнотекстового индекса. Форум работает. В очереди запросов ничего не задерживается, своп вободен, диски заняты на 1%, выполняя около 200 операций/сек
В общем как-то так.
Last edited by tarasus : 05-08-2015 at 11:45 AM.
Reason: Добавлено сообщение
AleX
Гость
Posts: n/a
@tarasus, придётся ещё форум обновить (до 3.8.8) или исправлять ошибки (диприкейты) ручками.
@tarasus
Простоузер
Join Date: Jan 2010
Location: N-Novgorod
Posts: 50
Версия vB: 3.8.x
Пол:
Reputation:
Опытный 18
Репутация в разделе: 9
1
@AleX,
Ошибки исправили, пых допилили до нужного поведения, это уже сделано. Поведать хочу о другом моменте.
Основная проблема, не позволявшая конвертировать медленный MyISAM в более быстрый InnoDB, была в возможности MyISAM создавать полнотекстовый индекс, который использовался в нескольких таблицах. например, в таблице vb3_post. В InnoDB возможность создания полнотекстового индекса появилась, как я уже упоминал, в Mysql версии 5.6. Таблицы были сконвертированы, индекс _как_бы_ создался, форум заработал. НО при попытке осуществить поиск по тексту темы выпадала ошибка БД (к сожалению, не успел сделать скрин _до_ того, как её вылечил), вкратце звучавшая как "невозможно выполнить запрос" "...SELECT postid, post.dateline USE INDEX (threadid)..."
Врукопашную запрос выполнялся без проблем, но при ручном запросе параметр "USE INDEX" не употреблялся.
Задумано - сделано.
Найден файл search.php, в нём два вхождения значения переменной $userid_index = "USE INDEX (threadid)";
дабы исключить из запросной строки явное указание на использование индекса комментируем обе строки двойным слэшем.
При попытке поиска по тексту темы результат не заставляет себя ждать - моментальное нахождение нужного текста.
Надеюсь будет кому-то полезным.
Luvilla
Гость
Posts: n/a
Quote:
Originally Posted by tarasus
к сожалению, не успел сделать скрин _до_ того, как её вылечил
а на почту ошибки не приходят...
Quote:
Originally Posted by tarasus
медленный MyISAM в более быстрый InnoDB
это тезис для обсуждения, но отнюдь не истина в последней инстанции
@tarasus
Простоузер
Join Date: Jan 2010
Location: N-Novgorod
Posts: 50
Версия vB: 3.8.x
Пол:
Reputation:
Опытный 18
Репутация в разделе: 9
0
Quote:
Originally Posted by Luvilla
а на почту ошибки не приходят...
к сожалению, не ко мне. Я там, как бы это сказать.... "неосновной"
Quote:
Originally Posted by Luvilla
это тезис для обсуждения, но отнюдь не истина в последней инстанции
не буду спорить, ибо я в б0льшей части - "системщик", т.е. поставить/настроить сервер, дать среду, права, настроить фаерволл, днс, etc,etc - это моё; а выбор табличного пространства БД или движка, который на этом всём будет крутиться - для меня пока не такой простой вопрос. Но я постепенно обучаюсь Соответственно в процессе "обучения" приходится оперировать определёнными категориями, ну и верить на слово людям, которые достигли многого в создании разных информационных ресурсов.
ЗЫ: я тут думал, что у меня таблица ibdata1 большая - занимает чуть менее 11 гигов. При наличии 16 гиг оперативки, рассуждал я, если эта база вся всосётся в память, а это весьма вероятно, свободной памяти останется немного и, возможно, оттого ввод/вывод притормаживает. Но когда товарищ показал мне на впске с 12ю гигами памяти свою БД, в которой ibdata1 весит 160 гигов..... Я понял, что моя база - это "песочница"
Но это по-большому счёту лирика.
ЗЫ2: всегда интересно послушать мнение знающих людей. Возможно эта информация поможет в дальнейшем
Тормозит MySQL при исполнении запросов
