VBsupport перешел с домена .ORG на родной .RU
Ура!
Пожалуйста, обновите свои закладки - VBsupport.ru
Блок РКН снят, форум доступен на всей территории России, включая новые терртории, без VPN
На форуме введена премодерация ВСЕХ новых пользователей
Почта с временных сервисов, типа mailinator.com, gawab.com и/или прочих, которые предоставляют временный почтовый ящик без регистрации и/или почтовый ящик для рассылки спама, отслеживается и блокируется, а так же заносится в спам-блок форума, аккаунты удаляются
Если вы хотите приобрести какой то скрипт/продукт/хак из каталогов перечисленных ниже: Каталог модулей/хаков
Ещё раз обращаем Ваше внимание: всё, что Вы скачиваете и устанавливаете на свой форум, Вы устанавливаете исключительно на свой страх и риск.
Сообщество vBSupport'а физически не в состоянии проверять все стили, хаки и нули, выкладываемые пользователями.
Помните: безопасность Вашего проекта - Ваша забота. Убедительная просьба: при обнаружении уязвимостей или сомнительных кодов обязательно отписывайтесь в теме хака/стиля
Спасибо за понимание
Доброго дня.
Поискал по форуму, найти ничего похожего, к сожалению, не удалось. Может быть кто знает, подскажите.
Сразу скажу некоторые вводные данные, может быть это важно. Форум переезжал с хоста на хост достаточно часто, помимо всего прочего были и ошибки по базе, и до сих пор есть чудеса типа бесследно пропавших разделов после некоторой реструктуризации. Пропадали запланированные задачи - основную часть из них восстановил, но тоже не факт, все, или нет. ну и после массированной ДДОС-атаки на форум были сделаны некоторые изменения для улучшения производительности, в том числе переделаны схемы MyIsam в InnoDB. Переделка была произведена средствами MySQL. Всё вроде бы выровнялось.
По прошествии некоторого времени с завидной регулярностью начала вылезать ошибка по базе. Оптимизация средствами воблы не помогла. Потом начались жутчайшие тормоза по базе, вследствие которых истекал таймаут ожидания ответа и веб-сервер, собственно, рисовал пользователям bad gateway.
Начали искать корень зла. Выяснили, что тормозит именно мускль и начинает он это делать волнообразно по мере подключения пользователей к форуму. При помощи одного очень полезного средства посмотрели, что самые длинные запросы (самые долгоиграющие) получаются по таблице vb3_session. Как оказалось, в таблице более 4 миллионов записей и поиск по ним почему-то производился ооооочень долго (хотя, по идее, должен быть индекс, но что с ним - неизвестно). Очистили таблицу (процесс длился около 15 минут) и пока жить стало намного легче.
В настоящий момент в этой таблице уже 1,5 миллиона записей. Производительность мускля пока не проверял, но, чувствую, она становится всё ниже и ниже.
Так вот собственно, вопрос. Насколько долго должны храниться записи в этой таблице и насколько вообще они важны? И, может быть, среди стандартных плановых задач по обслуживанию базы, есть процедура очистки, перестроения индексов, etc, etc, в подобных таблицах, содержащих служебные данные?
Параллельно другой вопрос - если внутренняя структура таблицы сейчас не MyIsam, а InnoDB, то запуск "оптимизации таблиц" в админке имеет эффект, или он уже как мёртвому припарка, и не выполняется?
Параллельно другой вопрос - если внутренняя структура таблицы сейчас не MyIsam, а InnoDB, то запуск "оптимизации таблиц" в админке имеет эффект, или он уже как мёртвому припарка, и не выполняется?
хм...
с InnoDB всё значительно сложнее, чем с MyIsam
при обнаружении проблем с таблицей и попытке её "починить" автоматическими средствами майсиквела часто происходит сбой
по моим данным - в разы чаще, чем с MyIsam
этот сбой зачастую приводит к автоматическому рестарту майсиквела
посмотрите в ПМА - состояние - там должна быть строка с содержанием
MySQL сервер работает Х дней, Х часов, Х минут и Х секунд. Время запуска: ХХХ.
Quote:
Originally Posted by tarasus
По прошествии некоторого времени с завидной регулярностью начала вылезать ошибка по базе.
В соседней вкладке открыто... пункт "Ежедневная чистка"?
*надо ещё раз слазить посмотреть в админке, может и правда не выполняется
** и правда такой задачи нет
Quote:
Originally Posted by Luvilla
хм...
с InnoDB всё значительно сложнее, чем с MyIsam
при обнаружении проблем с таблицей и попытке её "починить" автоматическими средствами майсиквела часто происходит сбой
...
Как починить средствами мускля, к сожалению, тоже не нашёл, всё встречается лишь про MyIsam, я имел в виду попытки запуска оптимизации таблиц из админки. Или при запуске этого процесса из админки, всё равно происходит "лечение" таблиц внутренними средствами мускля?
Quote:
Originally Posted by Luvilla
посмотрите в ПМА
pardon?
Code:
mysqld 5.0.95 up 40 day(s), 20:25 hrs
Разве что так. В админке в диагностике uptime стоит "3529457" - полагаю, в милисекундах
Quote:
Originally Posted by Luvilla
текст ошибки можно увидеть?
К сожалению, или, наоборот, к счастью, после очистки таблицы сессий она пока не вылазила и связка бд --> бэкэнд --> фронтэнд работает без сбоев.
Я к чему завёл тему-то: посмотрел список типовых крон-задач, вроде бы всё основное совпадает, но, вот, пары штук нет. Так как описания самих задач не нашёл, решил спросить с описанием проблемы и, по-сути, временным её решением "через задний проход". Но хочется, чтобы всё-таки база функционировала должным образом и подобной ошибки более не возникало.
А то после весенней атаки уже везде мерещатся враги....
Спасибо большое за ответ
tarasus добавил 14.01.2013 в 16:01
О, а правку сообщений у юзера тоже убрали.....
А описанием задачи ежедневной очистки можно полюбопытствовать? Ну и Ежечасных чисток тоже, если можно...
Last edited by tarasus : 01-14-2013 at 06:01 PM.
Reason: Добавлено сообщение
Luvilla
Гость
Posts: n/a
Quote:
Originally Posted by tarasus
up 40 day(s)
нормально, всё в порядке
если он вдруг рестартится по сбою, то это происходит раз в несколько минут
Quote:
Originally Posted by tarasus
А описанием задачи ежедневной очистки можно полюбопытствовать? Ну и Ежечасных чисток тоже, если можно...
боюсь, что этого нет... на русском - так точно мне не попадалось
открывайте файлы кронов из дистрибутива, и читайте
cleanup.php и cleanup2.php - прямо с самого начала,
PHP Code:
$vbulletin->db->query_write(" DELETE FROM " . TABLE_PREFIX . "session WHERE lastactivity < " . intval(TIMENOW - $vbulletin->options['cookietimeout']) . " ");
@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
боюсь, что этого нет... на русском - так точно мне не попадалось
открывайте файлы кронов из дистрибутива, и читайте
cleanup.php и cleanup2.php - прямо с самого начала,
...
на русский я даже и не рассчитываю.
Я имел в виду, можно ли посмотреть как у Вас выглядит сама задача в админке? В том плане, чтобы хотя бы видеть, какой конкретно файл запускается и с каким интервалом.
cleanup'ы сейчас почитаю, спасибо.
tarasus добавил 14.01.2013 в 16:26
"Имя переменной" совпадает с названием самого файла крона? Или оно по-большом счёту произвольное? Или где-то ещё оно фигурирует при других работах?
Last edited by tarasus : 01-14-2013 at 06:26 PM.
Reason: Добавлено сообщение
вопрос о таблице vb3_session
