Превышение лимита на использование cpu

Содержание:

Общая информация о нагрузке на CPU

Если вы получили уведомление о превышении лимита на использование CPU, это означает, что потребление CPU вашим аккаунтом превысило суточную норму. При превышении лимита нагрузки на CPU более чем на 3% от максимально установленного значения на тарифном плане и больше 4 раз за последние 7 дней, на хостинг накладывается блокировка.

Нагрузка CPU учитывается для всей услуги хостинга (всех добавленных сайтов). Самые посещаемые сайты оказывают наибольшую нагрузку на CPU.

С ограничениями по CPU на каждом тарифном плане вы можете ознакомиться по ссылке.

В этом случае на всех сайтах устанавливается форма базовой аутентификации. При обращении к сайту вы увидите сообщение:

Для получения доступа к сайту введите:

Далее вам необходимо выполнить рекомендации по решению проблемы, которые описаны ниже. После этого вы можете самостоятельно снять блокировку по инструкции.

Как снизить нагрузку на CPU?

Начните с просмотра статистики нагрузки на CPU:

На вкладке «Управление» вы можете увидеть показатель средней нагрузки на CPU. Для более подробного анализа нажмите по строке Статистика. Обратите внимание: Статистика по CPU не отображается, если нагрузка на сервер хостинга менее 1%.

Откроется статистика следующего вида:

Первое, на что стоит обратить внимание, это «Динамика нагрузки на процессор за последние 7 дней».

Динамика нагрузки на процессор за последние 7 дней

Если % потребления CPU (первый столбец) изменяется незначительно, выполните следующее: отключите тяжелые плагины CMS, настройте кеширование посредством CMS (для WordPress рекомендуем использовать WP Super Cache или WP-cache.com), установите таймаут обращения роботов к вашему сайту (см. ниже) или повысьте тарифный план, возможно, ваш сайт просто перерос параметры текущего тарифа и требует больших ресурсов.

Как снизить нагрузку на хостинг

Если же % потребления CPU вырос значительно или меняется скачкообразно, это может быть свидетельством DDOS-атаки, Brute-Force атаки или большого количества запросов от поисковых роботов. Читайте ниже, как это можно понять и что можно сделать.

Статистика запросов по User-Agent

С помощью данной статистики можно увидеть, насколько часто поисковые роботы посещают ваш сайт.

Если количество запросов большое, рекомендуем настроить файл robots.txt: установите таймаут обращения роботов к вашему сайту (от 10 секунд) при помощи директивы «Crawl-delay».

Внимание: не все User-Agent являются роботами, User-Agent показывает приложение, через которое происходило обращение к вашему сайту. То есть если вы явно не видите надписи bot, то проблема не в поисковых роботах.

Превышение лимита на использование CPU

Если вы получили уведомление о превышении лимита на использование CPU, это означает, что потребление ресурсов процессора вашим аккаунтом превысило суточную норму, установленную тарифным планом.

В письме от провайдера, как правило, сообщаются:

  • пункт Договора/Правил, который был нарушен;
  • суть нарушения;
  • текущее состояние аккаунта;
  • предлагаемые меры, которые клиенту необходимо выполнить для возобновления предоставления услуги.

Выявляем причину повышения нагрузки на хостинг

Первое, что необходимо сделать, это понять основную причину, по которой возрасла нагрузка на ЦП.

1. Нагрузка на CPU из-за неоптимальной работы скриптов или неоптимизированной базы данных

Оптимизация CMS: Отключите неиспользуемые и тяжелые плагины CMS, настройте кэширование посредством CMS (для WordPress например можно использовать WP Super Cache или WP-cache.com).

Оптимизация базы данных: Запросы к MySQL, которые выполняются более 0,5 секунд, часто создают избыточную нагрузку на дисковую систему сервера и на его процессор. Проверьте логи медленных запросов к БД (можно запросить у хостера) и выполните оптимизацию структуры БД, а также почистите её от неактуальной информации.

2. Избыточное число запросов к сайту

Повышение нагрузки на CPU может быть свидетельством большого количества запросов от поисковых и иных роботов, или, особенно при скачкообразном резком росте — свидетельством DDOS-атаки или Brute-Force атаки.

Читайте также:  Tv тюнер bbk smp022hdt2

Проверка источников запросов: откройте лог-файл со статистикой запросов по User-Agent — из него вы сможете понять, какие роботы с какой периодичностью обращаются к вашему сайту (например YandexBot, bingbot). В логах со статистикой по IP-адресам проверьте, не идёт ли с каких-либо IP огромный поток обращений (если да, то возможно это атака на сайт). Узнать больше информации про IP (кому он принадлежит) можно при помощи сервисов Whois.

Настройка ограничения для роботов: Настройте файл robots.txt: установите таймаут обращения роботов к вашему сайту при помощи директивы Crawl-delay:

— для отдельного бота:

— или сразу для всех ботов:

Настройка ограничений по IP-адресам: Для блокировки доступа по IP добавьте в файл .htaccess, находящийся в корневой папке сайта, следующие строки (в примере ниже блокируем доступ к сайту для IP-адресов 121.123.123.123 и 121.122.122.122):

3. Реальное увеличение посещаемости ресурса

С развитием сайта посещаемость его растёт, и чем выше посещаемость, тем больше нагрузка на CPU. В случае перехода порога посещаемости в 10000 уникальных посетителей в сутки на обычном виртуальном хостинге сайту будет однозначно тесно и необходимо переносить его на выделенный сервер.

Содержание

Введение.

В данной статье речь пойдет о так называемом «превышении лимита на использование системных ресурсов» или проще говоря «перегрузках» создаваемых аккаунтами пользователей, в ходе данного материала мы ответим на следующие вопросы:

  • что такое перегрузка?
  • почему блокировка?
  • откуда они берутся?
  • анализ перегрузки?
  • как с ними бороться?

Основным принципом виртуального хостинга или правильнее: «разделяемого» (от англ. гл. share – разделять, shared — общий) является предоставление свободных ресурсов без каких-либо ограничений, любому процессу в системе.

Процессом в системе может быть любая запущенная программа, вызываемый скрипт, запрос в базу данных, подключение по ftp,отправляемое получаемое письмо и много другое, таким образом все в системе представлено в виде процессов, каждый из которых потребляет определенное количество ресурсов от центрального процессора(ов) сервера, а так же оперативную память, пропускную способность канала и что немаловажно пропускную способность дисковой подсистемы (ввод/вывод). В один и тот же момент времени процессам, как правило необходимы разные ресурсы, так например один процесс может ожидать чтения данных с дисков, в то время как другой рассчитываться процессором (CPU), третий и вовсе находится в спящем состоянии ожидая действий из вне, такой подход работы позволяет размещать более чем одного пользователя на сервере существенно снижая конечную стоимость для клиентов, именно поэтому shared-хостинг стоит в разы дешевле VPS и выделенных серверов и именно поэтому ресурсы не могут быть ограничены принудительно.

Что же такое перегрузка?

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

Вот почему так важно не допускать подобных перегрузок, так как это не только мешает другим, но и в целом оказывает пагубное влияние на производительность.

Почему применяется блокировка?

Существует несколько видов блокировки:

Автоматическая блокировка веб-сайтов.

При этой блокировке вместо сайта устанавливается информационная страничка-заглушка с сообщением о временной блокировке. Письма с детализацией в данном случае не отправляется, сама блокировка временный характер и редко превышает 15 минут. В этом режиме cPanel/ftp/почта и другие сервисы доступны, поэтому если Вы увидели подобную заглушку на своем сайте, это первый признак о том, что с аккаунтом не все в порядке и следует вмешаться.

Полная блокировка аккаунта.

Не смотря на то, что мы всегда стараемся сначала отправлять уведомления с детализацией, пока ситуация еще исправима, но к сожалению это не всегда возможно, по следующим причинам:

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

Единственным вариантом в этих случаях является полная блокировка аккаунта.

Внимание:не рекомендуется указывать доверительный email с доменом расположенным на том же аккаунте, так как при его блокировке вы не сможете получить письмо с детализацией, не узнаете причину и не сможете вовремя отреагировать.

В случае тотальной блокировки следует обращаться в нашу службу технической поддержки через доверительный email или виртуальный офис. При этом Вам может быть предоставлен ftp/cPanel доступ для устранения причин перегрузки.

Читайте также:  Что такое ориентация в телефоне xiaomi

Откуда берутся перегрузки?

Причин появления перегрузок множество, в основном это:

  • Низкое качество кода, плохая архитектура движка, не оптимизированные скрипты, тяжелые запросы к БД.
  • Повышенная активность поисковых систем, ботов и т.п.
  • Высокая посещаемость

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

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

Третий случай встречается реже и при исключении первых двух является фактом нехватки ресурсов.

Анализ перегрузки?

Прежде чем бороться, надо понять причину, а для этого необходимо проанализировать детализацию нагрузки (высылаемую по почте), журналы доступа к сайту, провести анализ БД по средствам phpmyadmin и т.д. Далее мы рассмотрим пример присылаемой детализации перегрузки, поскольку перегрузки могут быть по различным ресурсам то и детализация может выглядеть по иному, мы рассмотрим лишь самый частый случай перегрузка центрального процессора PHP скриптами. В начале любой детализации находится имя аккаунта, которое совпадает с логином в cPanel, а так же указана суммарная нагрузка создаваемая всеми процессами аккаунта, по основным параметрам:

Обозначает потребление ресурсов центрального процессора(ов) и измеряется в %, при этом суммарное значение по нагрузке на центральный процессор может превышать 100%, т.к. На технических площадках могут использоваться многоядерные и многопроцессорные системы, таким образом задача запущенная на 2-х ядерном процессоре может занимать 200% и даже 800% в случае с 4-х процессорными 2-х ядерными системами.

Обозначает потребление оперативной памяти и измеряется в %, в целом превышение по оперативной памяти редкое явление.

Обозначает потребление дисковой полосы пропускания и измеряется в %

А так же ряд параметров несущих дополнительную информацию:

rss — размер процесса в оперативной памяти, измеряется в байтах
exe — Исполняемый файл
cmd — Командная строка
cwd — Текущая директория процесса

По PHP процессам так же существует статистика частоты их вызовов и выглядит она следующим образом:

В конце каждой детализации обязательно проставлен временной штамп:

Исходя из разобранной детализации можно сделать вывод, что перегрузка вызвана частым запуском скрипта banner.xml.php но что бы глубже понять причину необходимо заглянуть в «необработанные журналы доступа» через cPanel проанализировав откуда вызывался такой скрипт, а так же изучить исходный код сайта/движка. Помимо приведенной в этомй статье детализации могут быть указаны и другие параметры:

— Запросы к веб-серверу:

— Запросы к MySQL:

Как мне самостоятельно узнать текущую нагрузку?

Достаточно скачать Perl скрипт выводящий список процессов Вашего аккаунта. Распакуйте и сохраните скрипт в каталог например: public_html, обязательно убедитесь, что при загрузке скрипта в FTP-клиенте был выбран ASCII режим (при загрузке распакованного файла). Если файл передается в архиве ASCII режим не нужен.

Далее следует создать условия для корректного запуска скрипта:

  • Права у файла должны быть 755, могут быть изенены через файловый менеджер cPanel или поддерживающий chmod ftp-клиент
  • В папке где расположен скрипт должен быть разрешен запуск CGI для этого в файле .htaccess должна быть запись:

Теперь, если Вам понадобится список процессов Вашего аккаунта в любой момент времени заходим по ссылке http://ваш_домен/proc.pl

Как бороться с перегрузками?

Перед тем, как указать способы борьбы с перегрузками необходимо развеять часто встречающийся миф — посещаемость сайта не является показателем создаваемой им нагрузки, в некоторых ситуациях перегрузку может вызвать всего 1 скрипт запущенный через планировщик cronпри этом на сайте будет 0 посетителей, а на счетчиках 0 хитов, так же известны случаи, когда плохо написанный запрос к БД способен вызвать перегрузку соизмеримую сайтами посещаемостью в 5000 уникальных ipи т.п.

Поскольку единого средства борьбы с перегрузками не существует, перечислим лишь некоторые из них:

Оптимизация исходного кода.

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

Читайте также:  Что значит код ошибки 190

Оптимизация структуры БД и запросов к ней.

Так же опытный программист со знанием SQLможет найти узкое место в запросах и решить его построением удачных индексов для БД или переписав сами запросы сократить время их выполнения, известны случаи когда выборка по определенным запросам без индексов занимала более 100 секунд времени, а после построения индексов это время сокращалось до 3-5 секунд.

Кэширование.

Данный вид борьбы с перегрузками является палкой о двух концах, с одной стороны кэширование может помочь снизить нагрузку на CPU,так как не надо будет сотни раз генерировать один и тот же код, но с другой стороны если кэш размещается на диске, то это может вызвать нагрузку на дисковую подсистему или наоборот если кэш располагается в оперативной памяти, то это может существенно повысить её расход. Применяйте кэширование с осторожностью, там, где оно действительно необходимо.

Генерация статического контента.

Если на ваш сайт поступает большое количество однотипных запросов, разумным решением будет перевод части посещаемых страниц на статику, так например вывод главной страницы сайта средствами PHPсодержит в себе некоторое количество запросов к БД (например вывод новостей), вызов разного рода PHPфункций, потребление ресурсов CPUдля расчетов, а так же загрузку разных библиотек в оперативную память, в то время, как отдача статической страницы в сотни раз быстрее и ресурсосберегающая, так как требует только одну операцию чтения с диска и немного времени веб-сервера, что бы отдать её браузеру.

Для того, что бы статическая страничка регулярно обновлялась, можно добавить задание в планировщик cron,которое булдет генерировать статику из динамического скрипта раз в 5-10 минут, что обычно более чем достаточно. Как показывает практика: сайт с посещаемостью в всего-лишь в 50-70 человек в день на обычной CMSедва справлялся с нашествием поисковых ботов, а после генерации статической страницы, сайт мог обслуживать до 7000 посетителей не вызывая превышения лимитов, но конечно не каждый сайт может быть переведен на статику, поскольку все зависит от его специфики и характера запросов к нему.

Отказаться от всего лишнего.

Такой метод снижения нагрузки создаваемой аккаунтом можно проводить самостоятельно, из практики — высокую нагрузку вызывают разного рода веб-чаты, гостевые книги, а так же разного рода модули и дополнения, особенно это касается таких CMSкакWordPress, Joomla, Drupal и т.п.

Понижение активности ботов.

В данном случае пользователь, как правило сам провоцирует перегрузку регистрируя сайт по множеству каталогов, продавая рекламные ссылки (например SAPE),а так же не устанавливая ограничений для поисковых ботов. В случае с поисковыми системами их интенсивность можно регулировать путем установки переменно crawl-delayв файле robots.txt,что бы узнать подробнее следует обратиться к документации непосредственно поисковых систем, а так же сайт http://robotstxt.org.ru/. В случае с SAPEможем посоветовать использовать экстенсивные пути решения (п.9) или попытаться обратится непосредственно к разработчикам для создания какого-либо механизма регулирования активности.

Атаки отказа в обслуживании.

В данном случае наша компания Вам не сможет помочь, так как защита от подобных атак весьма дорогостоящее решение и как правило DDoS-атаки спровоцированы размещением нелегального или политического контента. Единственным решением при данной перегрузке может быть только переезд на хостинги с защитой от DDoS-атак или отказ от размещения провокационного контента.

CGI-скрипты.

Отдельное и редкое явление это перегрузка CGI-скриптами (perl/python/shell), в этом случае существует возможность их запуска с пониженным приоритетом через команду nice.Так же имеет смысл понизить интенсивность запуска cron-заданий если таковые имеются.

Наращивание производительности (экстенсивный путь).

Это самый простой способ решения проблем перегрузок, он рекомендуется только в том случае когда какая-либо оптимизация не представляется возможной или уже проведена и не принесла нужного эффекта. К данному методу относится разделение сайтов, путем покупки нескольких аккаунтов и вынесения разных частей сайта(ов) на них, таким образом можно разделять два три и более сайтов друг от друга и в сумме они не уже будут приводить к превышению лимитов. Так же возможен вариант отделения форума от основного сайта, таким образом нагрузка на сайт резко снижается и даже при каких-либо работах или блокировке сайт остается работать. Если разделение не применимо и ваш ресурс очень посещаем при максимальном уровне оптимизации, выход может быть только один — переход на решения с бОльшими ресурсами, такими как VPSили выделенный сервер.