Мучаю форум пол ночи, перешел с 4.2.5 на 4.5.4.2.
Как ни странно всё вроде бы нормально, кэш очистил в админке и на клоудфлаере.
Но почему то идёт нагрузка на базу данных 600%, хотя сейчас 3 часа ночи и на форуме максимум пару человек пишет.

Еще вот такая штука, некоторые данные не корректно отображаются:

 

 

 

Есть несколько десятков пользователей у кого так отображается, нашел их в базе данных core_follow_count_cache у которой тип InnoDB, 90% таблиц имеют MyISAM

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

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

Всё, что угодно, может грузить базу. Например, дыра в скрипте, китайские боты и т.д.
Зайдите в шелл и наберите команду top в терминале. Посмотрите, какой процесс грузит сервер.
Зайдите в логи доступа на сайт /var/log/httpd/, посмотрите, какие ip адреса.
Мне помогло забанивание Китая целиком. Скачать список китайских IP можно тут: https://www.ipdeny.com/ipblocks/data/aggregated/cn-aggregated.zone
Как забанить через nginx написано тут.

 

 

Edited 17 марта, 20213 yr by Zero108

В менеджере ISP Lite, кстати, есть бесплатная функция блокировки по странам без необходимости мучать nginx. 

2 часа назад, Zero108 сказал:

Всё, что угодно, может грузить базу. Например, дыра в скрипте, китайские боты и т.д.
Зайдите в шелл и наберите команду top в терминале. Посмотрите, какой процесс грузит сервер.
Зайдите в логи доступа на сайт /var/log/httpd/, посмотрите, какие ip адреса.
Мне помогло забанивание Китая целиком. Скачать список китайских IP можно тут: https://www.ipdeny.com/ipblocks/data/aggregated/cn-aggregated.zone
Как забанить через nginx написано тут.

 

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

Остался пока что вопрос с таблицами, около 10 таблиц имеют InnoDB в базе данных вместо MYISAM ну и до сих пор не отображаются у этих полозователей данные которые выше указал.

Перевести базу полностью в innodb предпочтительно. Периодически следите затем за размером файла /mysql_data/ibtmp1. Он может вырасти с 200 МБ до 30 ГБ и более, что приведет к коллапсу из-за нехватки места на сервере. Если версия mysql 5.7.x, то файл "обнуляется" периодически перезапуском сервиса командой service mysqld restart руками по ssh или через крон.

Edited 17 марта, 20213 yr by Zero108

точно помню что с перехода 4.4 на 4.5 есть фоновый процессы для обновления форума, нужно дождаться их завершения

7 минут назад, accop сказал:

точно помню что с перехода 4.4 на 4.5 есть фоновый процессы для обновления форума, нужно дождаться их завершения

 

Что именно изменится после завершения?
Уже прошло 12 часов после обновления

3 минуты назад, vsemmoney сказал:

Уже прошло 12 часов после обновления

зависит от размера форума и мощности сервера 

4 минуты назад, vsemmoney сказал:

Что именно изменится после завершения?

Описание патчей https://invisioncommunity.com/release-notes/

2 часа назад, Zero108 сказал:

Перевести базу полностью в innodb предпочтительно.

Перевёл сейчас таблицы в Innodb, база сразу выросла в 2 раза, было в районе гига, стало 2 гига. Нажал "Оптимизировать таблицы"

Таблица не поддерживает оптимизацию, выполняется воссоздание

Но меня больше удивило, что база в 2 раза больше стала, это нормально?
 

• MyISAM поддерживает сжатие таблиц в отличие от InnoDB.
• MyISAM имеет встроенные полнотекстовой поиск в отличие от InnoDB.
• InnoDB поддерживает транзакции в отличие от MyISAM.
• InnoDB поддерживает блокировки уровня строки (MyISAM - только уровня таблицы).
• InnoDB поддерживает ограничения внешних ключей (MyISAM - нет).
• InnoDB более надежна при больших объемах данных.
• InnoDB в теории немного быстрее.

Есть один очевидный (но не сразу) минус MyISAM, вытекающий из особенностей блокировок. Если в системе могут выполняться тяжелые SELECTы, то любой UPDATE на участвующие в нем таблицы будет ждать окончания SELECTа и блочить все дальнейшие запросы. Если с базой работают достаточно активно, то это не вариант.

Edited 17 марта, 20213 yr by Zero108