UMIhelp
Разработка сайта на UMI.CMS => Настройка системы и модулей => Тема начата: 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
-
попробовать отключить все что касается кеша.
-
Кэш на сайте отключен полностью. Или надо вручную удались содержимое каких-то папок? Может быть как-то почистить таблицы базы, в которых содержится инфа о запросах (они занимают процентов 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"
-
Вот скриншот из базы данных.
(https://lh4.googleusercontent.com/-LDjGLEvX98o/UktNgltalsI/AAAAAAAAGc8/x9YsKThwwiQ/s999/Raspp_Screen_MyAdmin.jpg)
-
Как я понял, это вы же спрашивали и на сайте ЮМИ.
Цитирую:
На вашем хостинге установлено ограничение на максимальное количество запросов ( 'max_questions' ) к базе данных в час, на уровне 1800 (current value: 1800).
Возможно, в этотй статье содержится много ссылок на другие страницы, которые добавлены макросом %content get_page_url()% (каждый вызов - запрос на получение пути по id)
Но в любом случае 1800 это как-то очень мало, либо у вас очень дешевый тариф: более-менее что-то приемлемое начинается с 1000 руб/месяц.
Вариантов у вас три:
1) попросить хостера увеличить предел
2) менять хостера (тариф)
3) уходить на vds
-
Владимир, спасибо за ответы! Да, я интересовался у хостера, но они решили, что речь идет об одновременных запросах и бодро отписали, что у на нашем тарифе возможное количество одновременных запросов равно 32. Видимо даже письмо мое не целиком прочли :) Хостинг - ру-центр. Пока менять не собираемся.
VDS... Боюсь, что ни у меня, ни у кого в компании нет квалификации - настраивать его.
Скажите, как по Вашему, почему эти сообщения стали появляться только после нашего лечения? Нет ничего подозрительного в скриншоте базы?
И, да, в СЗ я тоже написал, пока советуют обновить систему. Кажется это стандартный ответ...
-
Странно.. в моей практике были сайты на Ру-Центр на тарифе 201 и работали без проблем.
Из перечисленных вами файлов имеет наибольшее значение /docs/libs/root-src/index.php
Сам по себе он не содержит запросов, все вызовы идут через api. Если остальные файлы системы не повреждены (хотя это странно, почему там мало было заражено), то изменений в логике быть не должно и на количество запросов к БД не скажется.
Наиболее вероятно, что лечение совпало по времени с разрастанием БД; например, увеличили главное меню, да еще и с дочерними страницами, или количество баннеров, новостей в боковых блоках, логотипов со ссылками; и если до этого запросов на пределе хватало, то теперь перестало хватать.
Как проверить.
1) Все запросы в ЮМИ отправляются через функцию l_mysql_string. Дописать туда логирование запросов и посмотреть какие же вызовы идут и в каком количестве.
2) Возможно, вырос поток посетителей, или пришли боты, или кто-то развлекается спаривая ваш сайт. Смотреть логи доступа.
3) Может быть, у вас не один сайт с БД на аккаунте?
4) Упростить сайт: меню в 1 уровень, поснимать везде галочки "показывать подменю" (это очень часто не делают, а это по одному запросу с пункта меню на сканирование дочерних страниц), скрыть новостные блоки - и посмотреть станет ли лучше. Модуль Статистика в ЮМИ можно отключить для уменьшнния количества запросов.
-
Спасибо!
У меня, в свою, очередь есть подозрения на файл /docs/smu/core.php в отличии от других там был не большой блок "абракадабры", а был заменен один параметр во второй строке. Его (в нелеченном варианте) и упомянутый Вами index прилагаю. Буду признателен, если посмотрите - что там может быть не так? То есть в core точно что-то не так, но вопрос - что за параметр должен быть вместо вражеского кода?
Разрастание БД действительно произошло, но уже после блокировки сайта, потому я и спрашивал про эти статистические таблицы. Сейчас остановил сбор статистики, почистил память (с 2011 года) и, соответственно, они обнулились. Сейчас не могу поймать ошибку, у меня она не появляется, но хочется все же понять причину, иначе все будет очень зыбко.
-
Советую также провести оптимизацию сайта с точки зрения запросов к базе. Если необходимо, могу предоставить предварительный анализ в личном сообщении.
-
в index.php не нашел ничего подозрительного. Для сравнения прилагаю свой, правда, у нас, видимо, различаются версии, но в целом сходство есть.
А файла core.php в моей системе нет, видимо, или никогда не пользовался той функцией (что делает smu?) или удалил за ненадобностью. В другой системе он есть, но полностью обфуцирован. Первая строка содержит кодировку в base64, это правильно.