Повышенная нагрузка на сервер баз данных?

[mbosoy]

У меня форум версии 2.3.5.

База менее 100 Мб.

Посещаемость менее 300 чел/сутки.

 

Хостер: "Мастерхост". Тариф: "Эффективный" (300 руб./мес.)

 

Три года у них сидел без проблем, был весьма доволен. Последние полгода частит 502 ошибка или просто торможение форума.

 

На днях получил от них такое письмо, как выяснилось, они такие письма сотнями рассылают.

 

Вас приветствует компания .masterhost!

 

Уведомляем Вас, что работой базы данных MySQL uХХХХХ_forum создается повышенная нагрузка на

сервер баз данных. Примеры запросов находятся в прикрепленном файле.

 

Оптимизируйте, пожалуйста, Ваши скрипты, SQL-запросы и дайте нам знать о результатах.

 

Например, Вы можете использовать метод EXPLAIN для выяснения "тяжелых" запросов и создание

индексов (CREATE INDEX), тем самым снизив нагрузку на базу данных.

 

Обращаем Ваше внимание, что при сохранении нагрузки, мы будем вынуждены заблокировать

Вам услугу MySQL.

 

--

Служба технической поддержки компании .masterhost

support@masterhost.ru

 

 

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

 

 

5.1. Оператор, сохраняя за собой все права по Договору, вправе

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

оказание Услуг Абоненту и/или отключить программные и/или аппаратные средства

Абонента и/или удалить ресурс (сайт, веб-страницу) и/или регистрацию Абонента

(логин и пароль) и/или иной информации Абонента в случаях:

 

· превышения Абонентом установленных ограничений на использование ресурсов

системы, что приводит или может привести к заметному ухудшению качества

предоставляемого обслуживания/сервиса для других Абонентов, и эта проблема не

устраняется автоматически средствами операционной системы. При этом если

причину потребления ресурсов устранить не удается, Оператор может

порекомендовать Абоненту перейти на выделенный сервер или предложить

индивидуальные условия предоставления Услуг. В случае отказа Абонента Оператор

имеет право расторгнуть Договор из-за технической невозможности продолжения

оказания Услуг, без каких либо возмещений Абоненту.

--------------

 

В данном случае жёстких ограничений на процессорное время и на операции

ввода/ввывода к диску для одного SQL-запроса мы не устанавливаем, но требуем,

чтобы эти запросы не попадали в slow query log больше 200 в сутки:

 

http://dev.mysql.com/doc/refman/5.1/en/slow-query-log.html

 

В общем случае, если MySQL-запрос оценен системой как slow query, мы считаем,

что данные запросы следует оптимизировать, так как большинство из этих

запросов могут создавать нагрузку на систему.

 

Проблема возникает с запросом:

 

SELECT t.*,m.members_display_name as member_name, m.id as member_id, m.title

as member_title,me.avatar_location, me.avatar_size, me.avatar_type,p.* FROM

pref_topics t LEFT JOIN pref_members m ON ( m.id=t.starter_id ) LEFT JOIN

pref_member_extra me ON ( me.id=t.starter_id ) LEFT JOIN pref_posts p ON (

t.topic_firstpost=p.pid ) WHERE t.forum_id NOT IN (20,26,40) AND t.approved=1

AND (t.moved_to is null or t.moved_to = '') AND t.starter_id <> 0 ORDER BY

t.start_date DESC;

 

Если получить информацию о нём путём EXPLAIN, то видим в поле Extra - Using

filesort. В документации к mysql флаг Using filesort означает:

 

http://dev.mysql.com/doc/refman/5.0/en/using-explain.html

 

--------------

Using filesort

 

MySQL must do an extra pass to find out how to retrieve the rows in sorted

order. The sort is done by going through all rows according to the join type

and storing the sort key and pointer to the row for all rows that match the

WHERE clause. The keys then are sorted and the rows are retrieved in sorted

order. See Section 7.2.13, ?ORDER BY Optimization?.

--------------

 

Предлагается оптимизировать конструкию ORDER BY в запросе:

 

http://dev.mysql.com/doc/refman/5.0/en/ord...timization.html

 

Кроме того, результат выборки запроса достаточно большой, что так же приводит

к нагрузке по дисковым операциям ввода/вывода - узкое место в системе. Цифры

данные show profile: Block_ops_in - 11974, Block_ops_out - 79. Информация по

этим данным:

 

http://dev.mysql.com/doc/refman/6.0/en/profiling-table.html

 

В случае критической нагрузки мы вправе отключить ресурс.

 

Всего доброго.

 

--

С уважением,

Eldar Gaynetdinov,

.masterhost

 

 

Я в админке и так с самого начала выполнил все пункты оптимизации нагрузкит на сервер, в том числе у меня отключен пункт "Показывать дополнительные поля профиля при просмотре тем?".

 

Сейчас они, насколько я понял, докопались до сортировки. Я не программист и мне ихние каракули ничего не говорят.

 

У меня вопрос: это обоснованная претензия и нужно что-то оптимизировать? Или они гонят?

 

Если мне нужно в данном случае оптимизировать указанный выше запрос SELECT .... LEFT JOIN .... ORDER BY, то что именно и как именно мне нужно изменить? И поможет ли?

 

Очень расчитываю на помощь экспертов.

Спасибо,

Максим

 

П.С. Хостера всё равно менять буду, но и другой хостер то же самое может предъявить.

Изменено 14 Июня 2009 пользователем mbosoy

[ValRC]

Ничего не меняется со временем... Лет восемь сидел на мастерхосте...

Получил письмо: "Уведомляем Вас, что работой базы данных MySQL uХХХХХ_forum создается повышенная нагрузка на сервер баз данных. Примеры запросов находятся в прикрепленном файле."

На форуме в это время были только пара поисковиков.

Развод на VPS.

Буду переходить от них.

[avgaz]

П.С. Хостера всё равно менять буду, но и другой хостер то же самое может предъявить.

А вы отнеситесь к выбору более тщательно и возможно не предъявит или VPS берите там вам не скажут сами будете понимать что и куда.

Меня Года 4 назад так же мультихост разводил только не на vds а сразу на сервер ))) я выпал в осадок и взял VDS у другого и уже 4 года нет проблем

[levsha_kam]

С точно такой проблемой ушел к другому хостеру. (= 

 

Вообще где-то на форуме раньше описывали как снизить нагрузку за счет гостей и ботов... 

вот щас как раз ищу..

Изменено 22 Июля 2013 пользователем levsha_kam