Превышение Лимита На Использование Cpu

Здравствуйте! Использую хостинг на REG.RU. Пришло сообщение:

"Вы являетесь владельцем услуги хостинга - (Reg.Host-3 для leto-krasnodar.ru).
Уведомляем вас, что на аккаунте - превышен лимит использования ресурсов центрального процессора в 13% для тарифного плана Host-3.

В случае сохранения высокой нагрузки на CPU ваш аккаунт будет заблокирован через 24 часа."

Посещаемость сайта сейчас небольшая примерно 100 человек. Летом посещаемость была гораздо больше и таких сообщений не приходило. В настройках ничего не менял.

Как мне понять, что приводит к такой загрузке (20%) ЦПУ?

Здравствуйте! Использую хостинг на REG.RU. Пришло сообщение:

"Вы являетесь владельцем услуги хостинга - (Reg.Host-3 для leto-krasnodar.ru).
Уведомляем вас, что на аккаунте - превышен лимит использования ресурсов центрального процессора в 13% для тарифного плана Host-3.

Какая версия CS-Cart?

Чтобы не заблокировали, перенесите копию магазина на другой хостинг.

версия 4.2.3

Перенести можно и у них на тариф VIP, там можно грузить ЦП на 100%. Я просто разобраться хочу почему так стало.

версия 4.2.3

Перенести можно и у них на тариф VIP, там можно грузить ЦП на 100%. Я просто разобраться хочу почему так стало.

Проблема в версии, 4.2.х грузили сервера. Начиная с 4.3.х эта пробелема устранена.

Значит мне нужно обновляться?

Даниил и еще 1 вопрос, заметил что cs-cart стала создавать слишком много кеша и квота по количеству файлов быстро забивается. Приходится каждые несколько дней чистить кеш вручную.

Причем постепенно, если попробовать удалить все сразу система задумывается и виснит.

Хотя раньше я такого не наблюдал.

2015-09-02 10-16-01 Xостинг Host-3 для leto-krasnodar.ru - REG.RU.png

2015-09-02 10-17-17 server103.hosting.reg.ru -- ISPmanager 4.4 Professional.png

Значит мне нужно обновляться?

Даниил и еще 1 вопрос, заметил что cs-cart стала создавать слишком много кеша и квота по количеству файлов быстро забивается. Приходится каждые несколько дней чистить кеш вручную.

Причем постепенно, если попробовать удалить все сразу система задумывается и виснит.

Хотя раньше я такого не наблюдал.

Боты поисковиков не атакуют?

Поисмотрите access.log , скорее всего до вас дошла очередь активного индексирования. С этим связана и превышенная нагрузка на сервер.

Поставьте поисковикам ограничения

Даниил, мой сайт атакует bingbot.

compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"

Создает запрос через каждые 5 секунд

если в файле robots.txt прописать

User-agent: BingBot
Disallow: /

это его усмирит?

Даниил, мой сайт атакует bingbot.

compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"

Создает запрос через каждые 5 секунд

если в файле robots.txt прописать

User-agent: BingBot
Disallow: /

это его усмирит?

Честно говоря я не силен в robots.txt

Посмотрите https://yandex.ru/support/webmaster/controlling-robot/robots-txt.xml

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

Раз в 5 секунд это не много. Если он проходит фильтры то лучше закрыть фильтры целиком.

Есть тема про robots.txt отдельная.

Я понял, спасибо. Буду разбираться.

Я понял, спасибо. Буду разбираться.

Вот здесь тема:

http://forum.cs-cart.com/topic/25374-robotstxt/page-3#entry227028

Вот еще пару статей, как успокоить бот

https://www.siteground.com/kb/how_to_decrease_the_crawl_rate_of_bings_search_engine_bot/

http://www.bing.com/webmaster/help/crawl-control-55a30302

да .. подтверждаю .. кошмар прошел :) сейчас кэш в норме .. возможно это совпадение, но прекратилось когда поправил роботс

2 windknight могу свой окончательны роботс выложить в соответвующей ветке

Мой совет: если сервис не выдерживает индексации поисковыми ботами, то стоит задуматься о смене хостинга или оптимизации проекта. А от хостеров с «ограничениями по CPU» стоит убегать — размещать на них ничего серьёзнее домашней странички или блога не нужно.

Мой совет: если сервис не выдерживает индексации поисковыми ботами, то стоит задуматься о смене хостинга или оптимизации проекта. А от хостеров с «ограничениями по CPU» стоит убегать — размещать на них ничего серьёзнее домашней странички или блога не нужно.

так не набегаешься ... это я обновился до 4.3.1 :) https://yadi.sk/i/Yp7N1ALriyK7k там по факту не так страшно ... но тем не менее. это яндекс так "пошутил".

только, что разобрался как обходить потайными тропами заморочки cs-cart c правами, теперь новая напасть :)

Обновление 4.3.3.SP1 - 4.3.4

не хочет обновляться, говорит мало времени set_time_limit ... (типа при установке теперь это проверяется)

Ваш сервер имеет неправильное PHP скрипт настройки тайм-аута. Это может быть из-за ограничений на PHP set_time_limit функции или FastCGI "Тайм-аут" вариантов

в

php.ini

max_execution_time = 3600

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

так не набегаешься ... это я обновился до 4.3.1 :) https://yadi.sk/i/Yp7N1ALriyK7k там по факту не так страшно ... но тем не менее. это яндекс так "пошутил".

только, что разобрался как обходить потайными тропами заморочки cs-cart c правами, теперь новая напасть :)

Обновление 4.3.3.SP1 - 4.3.4

не хочет обновляться, говорит мало времени set_time_limit ... (типа при установке теперь это проверяется)

в

php.ini

max_execution_time = 3600

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

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

Значение директивы "max_execution_time" в php.ini может перекрываться настройками веб-сервера (Apache/NGINX) и настройками FastCGI.

Проверка была добавлена в промежуточтной версии 4.3.3.SP1 с целью исключить "зависания" при апгрейде (это довольно частая проблема у наших клиентов с ограничениями в настройках серверного ПО): на сервер отправляется запрос, который выполняется 6 минут. Если скрипт "умирает" раньше, то выводится сообщение о том, что применять обновление нежелательно. Однако, вы можете проигнорировать результат проверки и продолжить процесс установки на свой страх и риск.

Хорошего дня!

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

Значение директивы "max_execution_time" в php.ini может перекрываться настройками веб-сервера (Apache/NGINX) и настройками FastCGI.

Проверка была добавлена в промежуточтной версии 4.3.3.SP1 с целью исключить "зависания" при апгрейде (это довольно частая проблема у наших клиентов с ограничениями в настройках серверного ПО): на сервер отправляется запрос, который выполняется 6 минут. Если скрипт "умирает" раньше, то выводится сообщение о том, что применять обновление нежелательно. Однако, вы можете проигнорировать результат проверки и продолжить процесс установки на свой страх и риск.

Хорошего дня!

я и говорю .. новая напасть.

восемь лет всем все хватало, и другим скриптам и cs-cart и настройки веб сервиса ничего не перекрывали ничего не зависало .. а тут раз и не хватает .. я так понимаю это спецом сделано, чтобы обращаться к специалистам? некрасиво.

имхо сейчас вместо "10" у которых зависало появится "100" у которых не обновляется.

PS спасибо Даниилу, что в свое время надоумил обновляться на денвере ...

я и говорю .. новая напасть.

восемь лет всем все хватало, и другим скриптам и cs-cart и настройки веб сервиса ничего не перекрывали ничего не зависало .. а тут раз и не хватает .. я так понимаю это спецом сделано, чтобы обращаться к специалистам? некрасиво.

имхо сейчас вместо "10" у которых зависало появится "100" у которых не обновляется.

PS спасибо Даниилу, что в свое время надоумил обновляться на денвере ...

Да, это я надоумил добавить проверку и уведомление о рисках.

Потому что именно вы каждое обновление пугаете всех на форуме, что у вас ничего не проходит :)

Да, пусть лучше обратятся к профессионалам, чем нажмут "Обновить" в магазине размером 10гб на виртуальном хостинге. Так как в этом случае реанимация магазина занимает кучу времени и нервов.

Да, это я надоумил добавить проверку и уведомление о рисках.

Потому что именно вы каждое обновление пугаете всех на форуме, что у вас ничего не проходит :)

Да, пусть лучше обратятся к профессионалам, чем нажмут "Обновить" в магазине размером 10гб на виртуальном хостинге. Так как в этом случае реанимация магазина занимает кучу времени и нервов.

Даниил, ну не правда ... не каждое ... и как показывает итог, результат все таки не в моих кривых ручках. Если почитать форум многие сталкиваются с проблемами на одних и тех же обновлениях.

Ставлю пустой магаз .. 4.3.1 .. обновляю обновляю обновляю ... доходим до 4.3.4 .. все обновиться нельзя. Причем тут специалист? причем тут реанимация? Вы сами помогали мне в свое время обновляться, все нормально с таймингами .. а умная программка говорит, что нет и обновление не заканчивается :( Опять же, я благодарен Вам, что надоумили делать все на денвере .. это действительно очень удобно :) но с обновлениями на хостинге это не нормально.

PS вы надоумили команду и международной сборки тоже ? :)

но с обновлениями на хостинге это не нормально.

Проблема в хостинге. Денвер, xampp и хостинг - это веб-серверы. Если на денвере проходит, а на хостинге нет, то проблема в хостинге. Хостинг не подходит под требования необходимые для обновления. Он может идеально подходить для работы магазина, но для обновления он не подходит.