Превышение допустимых лимитов нагрузки на хостинге - Хостинг для Joomla

Здравствуйте, проблема для меня новая и неожиданная. Прошу помочь расшифровать сие послание от хостера.
Из этого письма я должен понять какие процессы привели к блокировке. Лимиты следующие CPU-20%, PIDS-20, SQL-до 1%, MEM-до 1%, Кол-во файлов-100 000
Единственное, что я понял - это превышение MEM в 3 раза и превышение SQL в 106 раз . Подскажите, пожалуйста, алгоритм последующих действий или мануал.
Вот письмо хостера:


Здравствуйте!

Аккаунт "vorona34" превысил допустимые лимиты нагрузки.
Так как данная нагрузка мешает нормальной работе сервера,
аккаунт будет отключен до выяснения обстоятельств автоматически!

LA=67
PIDS=10
CPU=0%
MEM=3%
SQL=106%

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ UID COMMAND (TOP)
-----------------------------------------------------------------------
 25086 vorona34 30 10 504568 42804 13776 S 0.0 0.3 0:00.05 1140 /usr/sbin/apache2 -k start
 25109 vorona34 30 10 504280 42588 13800 S 0.0 0.3 0:00.05 1140 /usr/sbin/apache2 -k start
 25140 vorona34 30 10 503164 42872 15168 S 0.0 0.3 0:00.01 1140 /usr/sbin/apache2 -k start
 25416 vorona34 30 10 585620 49528 16624 S 0.0 0.3 0:00.17 1140 /usr/sbin/apache23 -D php53 -k start
 25443 vorona34 30 10 503164 42860 15156 S 0.0 0.3 0:00.01 1140 /usr/sbin/apache2 -k start
 25457 vorona34 30 10 503164 42872 15168 S 0.0 0.3 0:00.00 1140 /usr/sbin/apache2 -k start
 25503 vorona34 30 10 583680 45460 14372 S 0.0 0.3 0:00.02 1140 /usr/sbin/apache23 -D php53 -k start
 25863 vorona34 30 10 503164 42872 15168 S 0.0 0.3 0:00.00 1140 /usr/sbin/apache2 -k start
 25864 vorona34 30 10 503164 42872 15168 S 0.0 0.3 0:00.00 1140 /usr/sbin/apache2 -k start
 25921 vorona34 30 10 503164 42872 15168 S 0.0 0.3 0:00.01 1140 /usr/sbin/apache2 -k start


Id User Host db Command Time State Info (SQL)
-----------------------------------------------------------------------
72191264 vorona34_makakam localhost vorona34_makakam Query 87 Opening tables SELECT t.* FROM term_node r INNER JOIN term_data t ON r.tid = t.tid INNER JOIN vocabulary v ON t.vid
72191491 vorona34_makakam localhost vorona34_makakam Query 78 Opening tables SELECT t.* FROM term_node r INNER JOIN term_data t ON r.tid = t.tid INNER JOIN vocabulary v ON t.vid
72192328 vorona34_turnik localhost vorona34_turnik Query 106 closing tables UPDATE `xpnkh_session`
SET `data` = '__default|a:11:{s:15:\"session.counter\";i:1;s:19:\"session.tim
72192377 vorona34_turnik localhost vorona34_turnik Query 178 closing tables SELECT m.id, m.title, m.module, m.position, m.content, m.showtitle, m.params,am.mirror_id, am.params
72192403 vorona34_turnik localhost vorona34_turnik Query 87 checking permissions SHOW FULL COLUMNS FROM `xpnkh_jshopping_product_labels`
72192404 vorona34_forex localhost vorona34_forex Query 69 Opening tables SELECT nt.type, nt.* FROM node_type nt ORDER BY nt.type ASC
72192434 vorona34_podushk localhost vorona34_podushk Query 95 closing tables SELECT *
FROM xpnkh_content
WHERE `id` = '75'
72192552 vorona34_turnik localhost vorona34_turnik Query 100 closing tables SELECT COUNT(*)
FROM xpnkh_banners as a
LEFT JOIN xpnkh_banner_clients AS cl ON cl.id = a.cid
WHERE
72192564 vorona34_podushk localhost vorona34_podushk Killed 96 
72192631 vorona34_podushk localhost vorona34_podushk Query 89 Opening tables SHOW FULL COLUMNS FROM `xpnkh_content`
72192640 vorona34_turnik localhost vorona34_turnik Query 114 Opening tables SELECT prod.product_id, pr_cat.category_id, prod.`name_ru-RU` as name, prod.`short_description_ru-RU
72192678 vorona34_turnik localhost vorona34_turnik Query 97 removing tmp table SHOW FULL COLUMNS FROM `xpnkh_jshopping_products_extra_fields`
72192717 vorona34_turnik localhost vorona34_turnik Query 87 checking permissions SHOW FULL COLUMNS FROM `xpnkh_jshopping_product_labels`
72192882 vorona34_turnik localhost vorona34_turnik Query 91 checking permissions SHOW FULL COLUMNS FROM `xpnkh_jshopping_products`
72193226 vorona34_turnik localhost vorona34_turnik Query 119 closing tables SELECT a.id, a.asset_id, a.title, a.alias, a.introtext, a.fulltext, CASE WHEN badcats.id is null THE
72193308 vorona34_turnik localhost vorona34_turnik Query 103 closing tables DELETE
FROM `xpnkh_session`
WHERE `time` < '1445840643'
72193347 vorona34_turnik localhost vorona34_turnik Query 105 closing tables SELECT `data`
FROM `xpnkh_session`
WHERE `session_id` = 'd72cf2978945f1ae65c7434733263493'
72193362 vorona34_podushk localhost vorona34_podushk Query 93 Opening tables SELECT a.id, a.asset_id, a.title, a.alias, a.introtext, a.fulltext, CASE WHEN badcats.id is null THE
72193386 vorona34_turnik localhost vorona34_turnik Query 60 Opening tables SELECT `data`
FROM `xpnkh_session`
WHERE `session_id` = '95d85ee5710e1517d5d0831a90db63ab'
72193387 vorona34_turnik localhost vorona34_turnik Query 60 Opening tables SELECT `data`
FROM `xpnkh_session`
WHERE `session_id` = 'f2655ca73e33ec4a7b8f96b9de5674b3'
72193390 vorona34_turnik localhost vorona34_turnik Query 53 Opening tables SELECT `data`
FROM `xpnkh_session`
WHERE `session_id` = '989f30cc1d7a83c278ccd0a73c901e78'
72193456 vorona34_turnik localhost vorona34_turnik Query 38 Opening tables SELECT `data`
FROM `xpnkh_session`
WHERE `session_id` = '7f6eeb9562ea943121ef878be3250d8c'
72193457 vorona34_turnik localhost vorona34_turnik Query 38 Opening tables SELECT `data`
FROM `xpnkh_session`
WHERE `session_id` = '64a811a5cfdc5604062761d1970fb7fd'
72193483 vorona34_forex localhost vorona34_forex Query 38 Opening tables SELECT 1 FROM access WHERE type = 'host' AND LOWER('95.108.132.179') LIKE LOWER(mask) AND status = 0
72193534 vorona34_tt localhost vorona34_tt Query 35 Opening tables SELECT `data`
FROM `c65mp_session`
WHERE `session_id` = '282b423a7b2a80b6d35dd70ed12938f9'
72193560 vorona34_turnik localhost vorona34_turnik Query 14 Opening tables SELECT `data`
FROM `xpnkh_session`
WHERE `session_id` = 'f69a63814d5913023216293f28de05d3'
72193561 vorona34_turnik localhost vorona34_turnik Query 14 Opening tables SELECT `data`
FROM `xpnkh_session`
WHERE `session_id` = '5af1b2cd10d9c7d3ff41f08b29bf095a'
72193572 vorona34_turnik localhost vorona34_turnik Query 14 Opening tables SELECT `data`
FROM `xpnkh_session`
WHERE `session_id` = 'c6b96a613ee73978dec662b831ede2a1'


Srv PID Acc M CPU  SS Req Conn Child Slot Client VHost Request (APACHE)
-----------------------------------------------------------------------


Если Вы готовы исправить данное нарушение, свяжитесь с нами.

Данное письмо информативное и было выслано системой автоматически!
Если у Вас возникли вопросы, обратитесь в службу поддержки.

Если у Вас возникли вопросы, обратитесь в службу поддержки.

Начните с этого

Поддержка посоветовала обратиться на форум Joomla.

Опять блокировка. Теперь превышение CPU=426.4%. Как такое, вообще, может быть?
Странно, что тишина в теме... У меня одного такие проблемы или тема не в той ветке?

Опять блокировка. Теперь превышение CPU=426.4%. Как такое, вообще, может быть?
Странно, что тишина в теме... У меня одного такие проблемы или тема не в той ветке?

То, что пишут 406% и т.д., конечно интересно, но это зависит еще, как минимум, от самого CPU

По факту, нужно смотреть на сайт. Для начала% какой размер БД общий? Давно ли Вы её оптимизировали? Если нет, то попробуйте запустить оптимизацию через тотже phpMyAdmin, панельку хостера, если она позволяет это сделать или через чудо-скрипт Sypex Dumper. Часто помогает, при чем на разных CMS.

Дальше же нужно смотреть непосредственно сайт, а именно какое действие приводит к этому. Например, нестандартный плагин и ошибка в цикличном операторе, когда функция вызова приводит к многократным действиям: Query 38 Opening tables SELECT `data`

По факту же, похоже, что у Вас ошибка непосредственно в коде сайта, так как по 38 одновременных выборок с таблицы - явно что-то не то.

Кэшь включен? Закройте админку htpasswd. Настройте таймаут ботам. Оптимизируйте скрипты. Можно отключить сжатие в конфигурации. Или в крайнем случае возьмите другой хостинг.

О, жизнь закипела ))
 "размер БД общий" - не знаю как посмотреть по всем сайтам. в бэкапе около 270 Мб. 2 сайта на друпале занимают 240 из них.
"Давно ли Вы её оптимизировали" - после первого краха. Сайты жили около суток после этого.

"Дальше же нужно смотреть непосредственно сайт, а именно какое действие приводит к этому. Например, нестандартный плагин и ошибка в цикличном операторе, когда функция вызова приводит к многократным действиям: Query 38 Opening tables SELECT `data`" - скажите, где подробно об этом можно почитать?

Кэш выключен.
Таймаут поставил после первого краха.

"Оптимизируйте скрипты" - что-то мне подсказывает, что это сделать не так легко как оптимизировать базу?
Сжатие отключено.

"Или в крайнем случае возьмите другой хостинг" с такими превышениями меня ни один хостинг не будет терпеть. Посоветуете?

В итоге, после второго краха и третьего произошедшего через 10 мин после включения сайтов. Поддержка тоже посоветовала закрыть доступ к админке. И даже подсказала как это сделать, после того как смешала меня с г...м. О чудо - уже больше суток сайты не отрубались.

Появился дополнительный вопрос: почему это помогло? (если помогло)

Что интересно "vorona34_forex Query 38 Opening tables SELECT"- это почти мертвый сайт, изменения вносились последний раз несколько лет назад.

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

Речь не о поисковых ботах, видимо, а ботах-ломальщиках?

access лог посмотрите, чтобы увидеть куда ходили и как часто.

Речь не о поисковых ботах, видимо, а ботах-ломальщиках?

Наверно это были они. Нужно смотреть лог доступа.

Что интересно "vorona34_forex Query 38 Opening tables SELECT"- это почти мертвый сайт, изменения вносились последний раз несколько лет назад.

Отписал Вам на e-mail. Думаю, что решим проблему. Встречались на днях с подобной

Наверно это были они. Нужно смотреть лог доступа.

Есть учебник по этой теме?

Можете помочь, с 1 февраля идет огромная нагрузка на хостинг, технических изменений не проводилось. Хостер ничего не предлагает.
Под спойлером статистика за предыдущие дни.


Скриншот 10 февраля

Опять beget.com с трюком о превышении СР? Уже не первый раз. Никто не знает, как они считают эти СР. Думаю, что у них дела идут не очень хорошо, вот и придумывают причины, чтобы заставлять клиентов перейти на более дорогой тариф.

Все было нормально, были мелкие проблемы, но с обновлением на версию Joomla 3.6 и переходом на php 7.0 сайт летал и нагрузка была в районе 20-30СР. Но потом бац 1.02.2017 и нагрузка 600% выше предела или 700СР (предел 65СР + доп за денежку 55СР). Ничего с сайтом совершенно не делалось.
Раньше никогда с ними проблем не было, отвечали на вопросы быстро, сейчас же по 4 часа жду ответа, так и вечером и ночью и в выходные перестали работать.
Что меня удивляет, везде в инете пишут обратитесь к хостеру, у них большой опыт  в решении таких проблем, должны помочь. А тут просто тишина и отписки. В итоге еще и отрубили пол функционала сайта.
Вот сижу и думаю что же делать. Видимо нужно искать новый хостинг.

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