UMIhelp

Разработка сайта на UMI.CMS => Настройка системы и модулей => Тема начата: Aksuk от 26 Сентября 2013, 00:14:09

Название: Ошибка после лечения
Отправлено: Aksuk от 26 Сентября 2013, 00:14:09
Добрый день!

Я все со своим проектом raspp.ru вожусь :)
После лечения (я сам наугад удалял вражеский код из системных файлов) стала возникать следующая ошибка типа "неперехваченное исключение": "Ошибка (databaseException): User 'raspp_cms00' has exceeded the 'max_questions' resource (current value: 1800) in query: SELECT id FROM cms3_hierarchy WHERE obj_id = '27901' AND domain_id = '1' AND lang_id = '1'
"

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

Список файлов, подвергшихся лечению с моей стороны:
/docs/js/cross-domain.php
/docs/index.php
/docs/libs/root-src/index.php
/docs/smu/core.php
/docs/smu/index.php
Название: Re:Ошибка после лечения
Отправлено: admin от 29 Сентября 2013, 11:26:39
попробовать отключить все что касается кеша.
Название: Re:Ошибка после лечения
Отправлено: Aksuk от 02 Октября 2013, 02:11:16
Кэш на сайте отключен полностью. Или надо вручную удались содержимое каких-то папок? Может быть как-то почистить таблицы базы, в которых содержится инфа о запросах (они занимают процентов 80% всей базы)? Беда в том, что я здесь вообще полный ноль.

Кстати, я нашел объект, который упоминался в сообщении об ошибке - обычная статья. Ее отключение ничего не дало, просто теперь ругань идет на другие запросы. Например: "Неперехваченное исключение Ошибка (databaseException): User 'raspp_cms00' has exceeded the 'max_questions' resource (current value: 1800) in query: SELECT rel_id FROM cms3_hierarchy_relations WHERE child_id = '463' ORDER BY id"
Название: Re:Ошибка после лечения
Отправлено: Aksuk от 02 Октября 2013, 02:33:59
Вот скриншот из базы данных.

(https://lh4.googleusercontent.com/-LDjGLEvX98o/UktNgltalsI/AAAAAAAAGc8/x9YsKThwwiQ/s999/Raspp_Screen_MyAdmin.jpg)
Название: Re:Ошибка после лечения
Отправлено: Vladimir от 02 Октября 2013, 10:20:49
Как я понял, это вы же спрашивали и на сайте ЮМИ.
Цитирую:
На вашем хостинге установлено ограничение на максимальное количество запросов ( 'max_questions' ) к базе данных в час, на уровне 1800 (current value: 1800).
Возможно, в этотй статье содержится много ссылок на другие страницы, которые добавлены макросом %content get_page_url()% (каждый вызов - запрос на получение пути по id)

Но в любом случае 1800 это как-то очень мало, либо у вас очень дешевый тариф: более-менее что-то приемлемое начинается с 1000 руб/месяц.

Вариантов у вас три:
1) попросить хостера увеличить предел
2) менять хостера (тариф)
3) уходить на vds
Название: Re:Ошибка после лечения
Отправлено: Aksuk от 02 Октября 2013, 23:06:08
Владимир, спасибо за ответы! Да, я интересовался у хостера, но они решили, что речь идет об одновременных запросах и бодро отписали, что у на нашем тарифе возможное количество одновременных запросов равно 32. Видимо даже письмо мое не целиком прочли :) Хостинг - ру-центр. Пока менять не собираемся.

VDS... Боюсь, что ни у меня, ни у кого в компании нет квалификации - настраивать его.

Скажите, как по Вашему, почему эти сообщения стали появляться только после нашего лечения? Нет ничего подозрительного в скриншоте базы?

И, да, в СЗ я тоже написал, пока советуют обновить систему. Кажется это стандартный ответ...
Название: Re:Ошибка после лечения
Отправлено: Vladimir от 03 Октября 2013, 13:03:28
Странно..  в моей практике были сайты на Ру-Центр на тарифе 201 и работали без проблем.

Из перечисленных вами файлов имеет наибольшее значение /docs/libs/root-src/index.php
Сам по себе он не содержит запросов, все вызовы идут через api. Если остальные файлы системы не повреждены (хотя это странно, почему там мало было заражено), то изменений в логике быть не должно и на количество запросов к БД не скажется.

Наиболее вероятно, что лечение совпало по времени с разрастанием БД; например, увеличили главное меню, да еще и с дочерними страницами, или количество баннеров, новостей в боковых блоках, логотипов со ссылками;  и если до этого запросов на пределе хватало, то теперь перестало хватать.

Как проверить.
1) Все запросы в ЮМИ отправляются через функцию l_mysql_string. Дописать туда логирование запросов и посмотреть какие же вызовы идут и в каком количестве.
2) Возможно, вырос поток посетителей, или пришли боты, или кто-то развлекается спаривая ваш сайт. Смотреть логи доступа.
3) Может быть, у вас не один сайт с БД на аккаунте?
4) Упростить сайт: меню в 1 уровень, поснимать везде галочки "показывать подменю" (это очень часто не делают, а это по одному запросу с пункта меню на сканирование дочерних страниц), скрыть новостные блоки - и посмотреть станет ли лучше. Модуль Статистика в ЮМИ можно отключить для уменьшнния количества запросов.

Название: Re:Ошибка после лечения
Отправлено: Aksuk от 04 Октября 2013, 10:48:25
Спасибо!
У меня, в свою, очередь есть подозрения на файл /docs/smu/core.php в отличии от других там был не большой блок "абракадабры", а был заменен один параметр во второй строке. Его (в нелеченном варианте) и упомянутый Вами index прилагаю. Буду признателен, если посмотрите - что там может быть не так? То есть в core точно что-то не так, но вопрос - что за параметр должен быть вместо вражеского кода?

Разрастание БД действительно произошло, но уже после блокировки сайта, потому я и спрашивал про эти статистические таблицы. Сейчас остановил сбор статистики, почистил память (с 2011 года) и, соответственно, они обнулились. Сейчас не могу поймать ошибку, у меня она не появляется, но хочется все же понять причину, иначе все будет очень зыбко.
Название: Re:Ошибка после лечения
Отправлено: e.ioffe от 04 Октября 2013, 12:19:33
Советую также провести оптимизацию сайта с точки зрения запросов к базе. Если необходимо, могу предоставить предварительный анализ в личном сообщении.
Название: Re:Ошибка после лечения
Отправлено: Vladimir от 04 Октября 2013, 14:53:54
в index.php не нашел ничего подозрительного. Для сравнения прилагаю свой, правда, у нас, видимо, различаются версии, но в целом сходство есть.

А файла core.php в моей системе нет, видимо, или никогда не пользовался той функцией (что делает smu?) или удалил за ненадобностью.  В другой системе он есть, но полностью обфуцирован. Первая строка содержит кодировку в base64, это правильно.