Повышение нагрузки на базу данных MySQL

Всем привет!
Случился резкий скачек нагрузки на базу данных MySQL, после чего хостинг ввел ограничения на мой аккаунт за превышение нагрузки 2500 CP в 4 раза. Помогите понять из-за чего это произошло. Также буду рад любым советам по уменьшению нагрузки на базу данных в ModX.

Вот тип процесса с наибольшей нагрузкой, который мне скинула тех поддержка Бегет:

SELECT SQL_CALC_FOUND_ROWS `Section`.`id` AS `section.id`, `Section`.`type` AS `section.type`, `Section`.`contentType` AS `section.contentType`, `Section`.`pagetitle` AS `section.pagetitle`, `Section`.`longtitle` AS `section.longtitle`, `Section`.`description` AS `section.description`, `Section`.`alias` AS `section.alias`, `Section`.`link_attributes` AS `section.link_attributes`, `Section`.`published` AS `section.published`, `Section`.`pub_date` AS `section.pub_date`, `Section`.`unpub_date` AS `section.unpub_date`, `Section`.`parent` AS `section.parent`, `Section`.`isfolder` AS `section.isfolder`, `Section`.`introtext` AS `section.introtext`, `Section`.`richtext` AS `section.richtext`, `Section`.`template` AS `section.template`, `Section`.`menuindex` AS `section.menuindex`, `Section`.`searchable` AS `section.searchable`, `Section`.`cacheable` AS `section.cacheable`, `Section`.`createdby` AS `section.createdby`, `Section`.`createdon` AS `section.createdon`, `Section`.`editedby` AS `section.editedby`, `Section`.`editedon` AS `section.editedon`, `Section`.`deleted` AS `section.deleted`, `Section`.`deletedon` AS `section.deletedon`, `Section`.`deletedby` AS `section.deletedby`, `Section`.`publishedon` AS `section.publishedon`, `Section`.`publishedby` AS `section.publishedby`, `Section`.`menutitle` AS `section.menutitle`, `Section`.`donthit` AS `section.donthit`, `Section`.`privateweb` AS `section.privateweb`, `Section`.`privatemgr` AS `section.privatemgr`, `Section`.`content_dispo` AS `section.content_dispo`, `Section`.`hidemenu` AS `section.hidemenu`, `Section`.`class_key` AS `section.class_key`, `Section`.`context_key` AS `section.context_key`, `Section`.`content_type` AS `section.content_type`, `Section`.`uri` AS `section.uri`, `Section`.`uri_override` AS `section.uri_override`, `Section`.`hide_children_in_tree` AS `section.hide_children_in_tree`, `Section`.`show_in_tree` AS `section.show_in_tree`, `Section`.`properties` AS `section.properties`, `User`.`username`, `Profile`.`internalKey`, `Profile`.`fullname`, `Profile`.`email`, `Profile`.`phone`, `Profile`.`mobilephone`, `Profile`.`blocked`, `Profile`.`blockeduntil`, `Profile`.`blockedafter`, `Profile`.`logincount`, `Profile`.`lastlogin`, `Profile`.`thislogin`, `Profile`.`failedlogincount`, `Profile`.`sessionid`, `Profile`.`dob`, `Profile`.`gender`, `Profile`.`address`, `Profile`.`country`, `Profile`.`city`, `Profile`.`state`, `Profile`.`zip`, `Profile`.`fax`, `Profile`.`photo`, `Profile`.`comment`, `Profile`.`website`, `Profile`.`extended`, `Ticket`.`id`, `Ticket`.`type`, `Ticket`.`contentType`, `Ticket`.`pagetitle`, `Ticket`.`longtitle`, `Ticket`.`description`, `Ticket`.`alias`, `Ticket`.`link_attributes`, `Ticket`.`published`, `Ticket`.`pub_date`, `Ticket`.`unpub_date`, `Ticket`.`parent`, `Ticket`.`isfolder`, `Ticket`.`introtext`, `Ticket`.`richtext`, `Ticket`.`template`, `Ticket`.`menuindex`, `Ticket`.`searchable`, `Ticket`.`cacheable`, `Ticket`.`createdby`, `Ticket`.`createdon`, `Ticket`.`editedby`, `Ticket`.`editedon`, `Ticket`.`deleted`, `Ticket`.`deletedon`, `Ticket`.`deletedby`, `Ticket`.`publishedon`, `Ticket`.`publishedby`, `Ticket`.`menutitle`, `Ticket`.`donthit`, `Ticket`.`privateweb`, `Ticket`.`privatemgr`, `Ticket`.`content_dispo`, `Ticket`.`hidemenu`, `Ticket`.`class_key`, `Ticket`.`context_key`, `Ticket`.`content_type`, `Ticket`.`uri`, `Ticket`.`uri_override`, `Ticket`.`hide_children_in_tree`, `Ticket`.`show_in_tree`, `Ticket`.`properties`, IFNULL(`TVimage`.`value`, '') AS `image` FROM `modx_site_content` AS `Ticket` LEFT JOIN `modx_site_content` `Section` ON `Section`.`id` = `Ticket`.`parent` LEFT JOIN `modx_users` `User` ON `User`.`id` = `Ticket`.`createdby` LEFT JOIN `modx_user_attributes` `Profile` ON `Profile`.`internalKey` = `User`.`id` LEFT JOIN `modx_site_tmplvar_contentvalues` `TVimage` ON `TVimage`.`contentid` = `Ticket`.`id` AND `TVimage`.`tmplvarid` = 1 WHERE  ( `Ticket`.`class_key` = 'Ticket' AND `Ticket`.`published` = 1 AND `Ticket`.`deleted` = 0 AND `Ticket`.`context_key` = 'b' )  GROUP BY Ticket.id ORDER BY RAND() DESC LIMIT 12\G

Добавлю лишь, что на сайте около 275К тикетов. Нагрузка идет именно на базу данных. Заранее благодарю!

brioni

26 июня 2016, 20:36

3 071

Комментарии: 13

Максим

27 июня 2016, 01:03

Есть мнение, что проблема может быть в SQL_CALC_FOUND_ROWS.

brioni

27 июня 2016, 15:53

Спасибо за ссылку! Скорее всего так и есть, ибо на сайте 275 000 тикетов.
Жаль, что в публикации тема до конца не раскрыта, а именно нет инструкции как это исправить.

brioni

27 июня 2016, 16:27

Мда, действительно на сайте перестала работать кнопка «загруть ещё» сниппета PdoPage:

<div id="pdopage">
                            <div class="rows">
                            [[!pdoPage?
                                  &element=`getTickets`
                                  &ajaxMode=`button`
                                  &limit=`16`
                                  &tpl=`tickets-4-col`
                                  &includeTVs=`image,time`
                                  &sortby=`views`
                                  &select=`{"View":"COUNT(DISTINCT View.uid) as views"}`
                                  &leftJoin=`{"View":{"class":"TicketView","alias":"View","on":"Ticket.id=View.parent"}}`
                                  &scheme=`uri`
                            ]]
                            </div>
                            <div class="clearfix"> </div>
                            [[!+page.nav]]
                        </div>

Может проблема в параметрах &select= и &leftJoin=, а перегруз базы из-за большого кол-ва тикетов (275К)?

Raimei

27 июня 2016, 04:48

Пора бы вам на сайте провести оптимизацию мало-мальскую. Пишите на почту, помогу чем смогу)
lооnysnоw{сoбaka}gmаil{тoчkа}.cоm

brioni

27 июня 2016, 15:55

Согласен. Приму к сведению.

Роман

27 июня 2016, 10:38

Посмотри логи сервера, кто у тебя лазает на сайте!? У меня была та же проблема, только с нагрузкой на процессор, как оказалось, цела куча ботов/пауков и прочей ереси, которая мне даром не нужна. Заблокировал их в .htaccess и жизнь наладилась, нагрузка упала в 2-3 раза! Ну это так как вариант оптимизации, может решит, а может на будущее!

brioni

27 июня 2016, 16:09

Посмотрел — роботов действительно много, но они гугловские — скорее-всего полезные)) Думаю что-то «сломалось», причем там, где меня никто не ждет.
Как вариант оптимизации учту, спасибо!

Роман

27 июня 2016, 16:13

… а за что минусим!?

brioni

27 июня 2016, 16:16

Эт не я. В доказательство смог поставить плюс — теперь по нулям.

Василий Наумкин

27 июня 2016, 17:45

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

Неа.

Если на сайте 275 000 тикетов, то ничего не сломалось. Просто очень трудно их считать на дешевом хостинге.

Пора подумать или о кастомной оптимизации запросов, или переезде на свой\крутой хостинг.

brioni

27 июня 2016, 20:00

Похоже на то

Владимир Кисилица

03 августа 2016, 20:30

275к тикетов и сортировка по RAND(). Если есть возможность, лучше откажитесь от такой сортировки, нагрузка значительно упадет.

brioni

04 августа 2016, 20:21

в разделах сортировка по количеству просмотров:

&sortby=`views`
&select=`{"View":"COUNT(DISTINCT View.uid) as views"}`
&leftJoin=`{"View":{"class":"TicketView","alias":"View","on":"Ticket.id=View.parent"}}`

Пробовал убрать — не помогает. Но так как других вариантов пока нет, буду экспериментировать в данном направлении. Спасибо!

Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.

Повышение нагрузки на базу данных MySQL

Комментарии: 13

Здесь упомянуты