Что такое процессорная нагрузка на сайт

Обновлено: 14.01.2025

Материал, перевод которого мы сегодня публикуем, посвящён поиску узких мест в производительности серверов, исправлению проблем, улучшению производительности систем и предотвращению падения производительности. Здесь, на пути к решению проблем перегруженного сервера, предлагается сделать следующие 4 шага:

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

1. Оценка ситуации

Когда трафик перегружает сервер, узким местом производительности могут стать процессор, сеть, память, дисковая подсистема ввода-вывода. Определение того, что именно вызывает проблему, позволяет сконцентрировать усилия на самом важном. Рассмотрим некоторые особенности анализа важнейших серверных подсистем.

Процессор. Если использование процессора постоянно находится на уровне, превышающем 80%, это значит, что сервер перегружен и нужно выяснить причины возникновения подобной ситуации. Дело в том, что производительность серверов часто падает при достижении нагрузки на процессор 80-90%. Если же нагрузка близка к 100%, падение производительности становится более заметным. Нагрузка на процессор, которую создаёт обработка единственного запроса, крайне мала. Но когда запросов очень много, например, на пиках активности пользователей, даже «лёгкие» запросы могут перегрузить сервер. Уменьшить уровень использования процессора можно, перенеся сервер в другое окружение, снизив объём сложных вычислительных операций, ограничив количество запросов, поступающих к серверу.
Сеть. В периоды, когда к серверу поступает очень много запросов, сеть, к которой подключён сервер, должна справляться с передачей данных от пользователя серверу и в обратном направлении. Некоторые сайты, зависящие от хостинг-провайдеров, могут испытывать проблемы, достигая лимитов на передачу данных. Избавиться от этой неприятности можно, снизив объёмы данных, которыми обмениваются сервер и клиентские системы.
Память. Если в системе недостаточно памяти, данные приходится выгружать на диск. Диск работает значительно медленнее, чем память. В результате такая ситуация может привести к замедлению работы серверного приложения. Если вся память сервера заполнена, это может привести к ошибкам нехватки памяти (Out Of Memory, OOM). Устранить эту проблему, можно, оптимизировав выделение памяти, исправив утечки памяти и оснастив сервер большим количеством памяти.
Дисковая подсистема ввода/вывода. То, с какой скоростью данные можно записывать на жёсткий диск, и то, с какой скоростью их можно с него читать, зависит от самого диска. Если пропускная способность дисковой подсистемы является узким местом сервера, смягчить эту проблему можно, увеличив объём данных, кешируемых в памяти (правда, платой за это станет повышенное потребление памяти). Если кеширование не помогает — вполне возможно, что решить проблему поможет обновление дисковой подсистемы сервера.

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

2. Стабилизация сервера

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

▍Ограничение скорости обработки запросов

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

Хотя отказ от обработки запроса — мера простая и действенная, лучше всего снижать нагрузку на сервер, занимаясь ограничением числа поступающих к нему запросов средствами некоей внешней системы. Это может быть, например, балансировщик нагрузки, обратный прокси-сервер или CDN. Ниже приведены ссылки на инструкции по работе с несколькими системами такого рода:

Диагностика

Запустите Lighthouse и взгляните на показатель Serve static assets with an efficient cache policy для того чтобы увидеть список ресурсов с коротким и средним временем кеширования (Time To Live, TTL). Проанализируйте ресурсы, перечисленные в списке, и рассмотрите возможность увеличения их TTL. Вот ориентировочные сроки кеширования, применимые к различным ресурсам.

Статические ресурсы нужно кешировать на длительный срок (1 год).
Динамические ресурсы нужно кешировать на короткий срок (3 часа).

Настройка кеширования

Нужно записать в директиву max-age заголовка Cache-Control необходимое время кеширования ресурса, выраженное в секундах. Вот инструкции по настройке этого заголовка в разных системах:

▍Постепенное сокращение возможностей системы

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

3. Улучшение системы

▍Использование CDN

Задача по обслуживанию статических ресурсов может быть переложена с сервера на сеть доставки контента (Content Delivery Network, CDN). Это позволит снизить нагрузку на сервер.

Основная функция CDN заключается в быстрой доставке материалов пользователям благодаря использованию большой сети серверов, расположенных поблизости от пользователей. Кроме того, некоторые CDN предлагают дополнительные возможности, связанные с производительностью. Среди них — сжатие данных, балансировка нагрузки, оптимизация медиа-файлов.

Настройка CDN

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

Оптимизация использования CDN: исследование ситуации

Для того чтобы идентифицировать ресурсы, которые обслуживаются не с помощью CDN (но должны выдаваться пользователям с CDN), можно воспользоваться WebPageTest. На странице результатов щёлкните по прямоугольнику, подписанному как Effective use of CDN и просмотрите список ресурсов, которые следует обслуживать средствами CDN.

Результаты, выдаваемые WebPageTest

Решение проблем

Если ресурсы не кешируются с помощью CDN, выясните, выполняются ли следующие условия:

У ресурса есть заголовок Cache-Control: public.
У ресурса есть заголовки Cache-Control: s-maxage, Cache-Control: max-age или Expires.
У ресурса есть заголовки Content-Length, Content-Range или Transfer-Encoding.

▍Масштабирование вычислительных ресурсов

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

Диагностика

Высокий показатель, характеризующий время до первого байта (Time To First Byte, TTFB), может быть признаком того, что сервер приближается к пределам своих возможностей. Найти сведения о TTFB можно в разделе Reduce server response times (TTFB) отчёта Lighthouse.

Для более глубокого исследования ситуации нужно воспользоваться каким-нибудь средством мониторинга и проанализировать использование процессора. Если текущее или прогнозируемое значение загрузки процессора превышает 80% — это значит, что нужно задуматься о повышении мощности сервера.

Решение проблем

Добавление в систему балансировщика нагрузки позволяет распределять трафик между множеством серверов. Балансировщик нагрузки находится перед пулом серверов и распределяет трафик на подходящие серверы. Облачные провайдеры предлагают пользователям балансировщики нагрузки (GCP, AWS, Azure), но можно пользоваться и собственным балансировщиком, применив HAProxy или NGINX. После того, как балансировщик нагрузки готов к работе, в систему можно добавлять дополнительные серверы.

В дополнение к балансировке нагрузки большинство облачных провайдеров предлагает услуги по автоматическому масштабированию вычислительных мощностей (GCP, AWS, Azure). Автоматическое масштабирование связано с балансировкой нагрузки. А именно, при автоматическом масштабировании ресурсов в моменты высокой нагрузки производится выделение дополнительных ресурсов, а в периоды низкой — отключение ненужных ресурсов. Но, даже учитывая это, нужно отметить, что автоматическое масштабирование — это тоже не универсальное решение. Для автоматического запуска серверов нужно время. Конфигурации автоматического масштабирования требуют серьёзной настройки. Поэтому до применения сложной системы автоматического масштабирования стоит опробовать сравнительно простую конфигурацию с балансировщиком нагрузки.

▍Использование сжатия данных

Текстовые ресурсы нужно сжимать с использованием алгоритма gzip или brotli. В некоторых случаях сжатие может помочь в сокращении размеров таких ресурсов примерно на 70%.

Диагностика

Для того чтобы найти ресурсы, нуждающиеся в сжатии, можете воспользоваться показателем Enable text compression из отчёта Lighthouse.

Решение проблем

Для включения сжатия нужно отредактировать настройки сервера. Вот подробности об этом:

▍Оптимизация изображений и других медиа-материалов

На изображения приходится основной объём материалов большинства веб-сайтов. Оптимизация изображений может привести к значительному уменьшению размеров материалов сайта. При этом такая оптимизация выполняется достаточно быстро.

Диагностика

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

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

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

Решение проблем

Сначала поговорим о том, что стоит предпринять в том случае, если у вас мало времени.

В такой ситуации стоит обратить внимание на большие изображения, и на изображения, которые загружаются чаще других. Обнаружив их, их надо подвергнуть ручной оптимизации, воспользовавшись инструментом наподобие Squoosh. Хорошими кандидатами на оптимизацию обычно являются большие фотографии. Например, взятые с ресурса вроде Hero Images.

Вот на что надо обращать внимание, оптимизируя изображения:

Размер: изображения не должны быть больше, чем нужно.
Сжатие: в целом можно отметить, что сжатие с уровнем качества 80-85 обычно почти не ухудшает внешнего вида изображений, но при этом позволяет избавиться от 30-40% размеров файлов изображений.
Формат: храните фотографии в формате JPEG, а не PNG. Для анимированного контента используйте MP4, а не GIF.

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

▍Минификация JavaScript- и CSS-кода

Минификация кода позволяет уменьшать его размер, удаляя ненужные символы.

Диагностика

Взгляните на показатели Minify CSS и Minify JavaScript отчёта Lighthouse для того чтобы выявить ресурсы, нуждающиеся в минификации.

Решение проблем

Если у вас мало времени — сосредоточьтесь на минификации JavaScript-кода. На большинстве сайтов объём JavaScript-кода превышает объём CSS-кода, поэтому такой ход даст лучшие результаты. Вот материал о минификации JavaScript, а вот — о минификации CSS.

4. Мониторинг сервера

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

В уведомлениях должны содержаться метрики, которые последовательно и точно описывают проблемы. Например, время ответа сервера (latency) — это метрика, которая особенно хорошо для этого подходит: она позволяет выявить большое количество проблемных ситуаций и напрямую связана с тем, как сервер воспринимается пользователями. Уведомления, основанные на низкоуровневых метриках, вроде уровня использования процессора, могут играть роль полезного дополнения, но они способны указать лишь на небольшую часть возможных проблем. Кроме того, уведомления должны быть основаны не на средних показателях, а на показателях, соответствующих 95-99 перцентилям. В противном случае анализ средних значений может легко привести к пропуску проблем, которые не затрагивают всех пользователей.

Настройка мониторинга

Все основные облачные провайдеры предоставляют клиентам собственные инструменты мониторинга (GCP, AWS, Azure). Кроме того, тут можно отметить инструмент Netdata — отличную бесплатную опенсорсную альтернативу инструментам провайдеров. Вне зависимости от того, чем именно вы пользуетесь, вам понадобится установить на каждый сервер, который нужно мониторить, приложение-агент. После завершения настройки системы не забудьте настроить уведомления. Вот инструкции по настройке разных средств мониторинга:

Итоги

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

Что такое нагрузка на CPU

Нагрузка на CPU, в контексте хостинга, это процентная доля вашего использования ресурсов центрального процессора сервера в рамках вашего тарифного плана.

При аренде вами шаред хостинга, вы априори делите CPU с другими пользователями хостинга. То есть вы по определению не можете использовать 100% ядра сервера.

Именно по этому при аренде общего хостинга вам нужно выяснить какая нагрузка на CPU вам разрешена по вашему тарифному плану.

Найти эти данные вы можете в договоре с хостингом. Называться данный параметр будет, скорее всего, так «максимальное суммарное потребление ресурсов процессора в сутки», измеряться может в минутах или процентах. Всё зависит от ПО хостинга.

Для администратора WordPress важно понимать, что нагрузка на сервер необязательно связана с правильной работой сайта. Если вы установили плохо «собранный» плагин или программный код создал бесконечный цикл или неправильное регулярное выражение, то нагрузка на CPU возрастёт кратно.

Помимо этого, есть нагрузка на CPU со стороны базы данных MySQL. Она лимитирована в меньшей степени, но она есть.

Итак, каждый раз, когда посетители вашего сайта его просматривают и каждый раз когда вы его администрируете, создаётся нагрузка на CPU вашего сервера. Однако эта нагрузка также создается, когда ваш сайт посещают законные или атакуют незаконные боты.

Чтобы снизить нагрузку на сайт со стороны законных ботов, от них закрывают часть каталог сайта в файле robots.txt . Это не единственное назначение этого файла и о нём мы поговорим в отдельной статье.

Как подсчитывается нагрузка на CPU

Нагрузка на CPU считается как время, которое тратит процессор сервера на обработку процессов пользователей. Какие при этом происходят процессы неизвестно. Однако их можно понять по логам веб-сервера (Apache). В них вы найдете дату, время, название процесса и кол-во тактов, которые потратил процессор на работу этого процесса.

Для WordPress максимальную нагрузку могут создавать:

экспорт и импорт БД (резервное копирование);
пиковая посещаемость сайта;
не оптимизированная БД;
невалидный программный код скрипта;
попытки взлома;
неправильно написанные плагины.

Где посмотреть нагрузку на CPU?

В панели управления вашего хостинга должен быть раздел: Статистика CPU, Нагрузка и т. п. В этом разделе будут данные, скорее в виде графика, с указанием суточного лимита и нагрузкой вашего сайта (посуточно, еженедельно, по месяцам). Пример такого графика на фото.

Почему нагрузка на CPU должна контролироваться?

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

Как уменьшить нагрузку?

Кратковременные или пиковые нагрузки можно анализировать по лог-файлам вашего сайта.

Периодические (систематические) повышенные нагрузки нужно анализировать по графику нагрузок с коротким временным интервалом (если он доступен).

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

Повышенную нагрузку от ненужный поисковых ботов вы можетt снизить в файле robots.txt , создав там директиву crawl-delay или закрыть неважные разделы сайта от обхода ботов.

Можно управлять нагрузкой директивами для веб-сервера Apache в файле .htaccess . Там вы сможете использовать user-agent для ограничений.

Можно управлять нагрузкой через плагины безопасности. В них есть блокировка пользователей и ботов по их IP, стране и т. п.

Чтобы нагрузка на CPU снизилась, администратор WordPress должен использовать кэширование средствами CMS. То есть установить плагин кеширования (на выбор): WP Super Cache, W3 Total Cache, WP Rocket, WP Fastest Cache, Comet Cache, Autoptimize.

Заключение

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

Нагрузка на CPU ( C entral P rocessor U nit - центральный процессор сервера) - это процентное отображение использования ресурсов CPU сервера Вашим аккаунтом. Она отображается в процентах от общего потребления ресурсов процессора: 100% - полная загрузка одного ядра, 200% - полная загрузка двух ядер. Нагрузка может быть вызвана как полезными математическими операциями, так и не оптимизированным программным кодом (например бесконечный цикл, или неправильно составленное регулярное выражение). Нагрузка на CPU так же создается при выборках данных из баз данных MySQL. Зачастую нагрузка создается посетителями сайта - как "живыми" людьми, пролистывающими Ваш сайт, так и поисковыми роботами, которые индексируют сайты с только им известной частотой, если не сделано нужных настроек в файле robots.txt.
Подчеркнем: нагрузка на CPU не всегда вызвана высокой посещаемостью сайта! Высокая нагрузка может быть вызвана тяжелыми неоптимизированными вычислительными функциями, которые запускают скрипты аккаунта.

Нагрузка на сервер считается количеством процессорного времени потраченного сервером на обработку процессов пользователей. Учитывается то, сколько потребляли исполняемые процессы пользователя, а также затраченные ресурсы MySQL. Подробности того, чем же конкретно заняты пользовательские процессы, системе учёта неизвестны. Это можно косвенно или явно увидеть по логам веб-сервера - система указывает на дату и время, название процесса и количество тактов процессора, потраченное на работу данного процесса.

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

Для удобства пользователя в панели управления хостингом есть график (раздел «Аккаунт» → «Статистика CPU, MySQL»), на котором указана максимально допустимая для текущего тарифного плана нагрузка, а также имеется возможность просматривать отдельно статистику нагрузки на CPU, и отдельно статистику нагрузки на MySQL.

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

Кроме того, внезапные скачки нагрузки могут означать то, что Ваш сайт пытаются взломать или он уже взломан.

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

Иногда скрипты пользователя потребляют больше, чем положено по тарифному плану. Жёсткое ограничение ресурсов означает аварийное завершение скриптов пользователя и в конечном итоге, нестабильную работу его сайтов.

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

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

Для поисковых ботов достаточно задать crawl-delay или в файле robots.txt описать, какие разделы сайта можно, а какие нельзя индексировать. Примеры использования robots.txt можно увидеть здесь.

Любую нежелательную активность можно ограничить средствами веб-сервера. Это можно сделать через файл .htaccess. Пример ограничения по user-agent:

Пример ограничения по IP-адресу:

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

Если Вы разработчик, можем предложить подключение модуля php XHprof. Вместе с инструментами веб-разработчика в браузере он предоставляет достаточно информации для профилирования кода.

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

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

Если бороться с нагрузкой нет возможности или желания, есть несколько решений:

воспользоваться дополнительной услугой «увеличенная нагрузка CPU»;
арендовать VDS - все его ресурсы виртуального выделенного сервера будут полностью в Вашем распоряжении. Минусы этого решения - администрированием сервера и резервным копированием данных Вам придётся заниматься самостоятельно или покупать дополнительную услугу «расширенное администрирование»;
арендовать выделенный сервер. Вы получаете привычное Вам окружение, Вам не приходится заботиться об администрировании и резервном копировании, все заботы о сервере берем мы в свои руки.

Удачной работы! Если возникнут вопросы - напишите нам, пожалуйста, тикет из раздел «Помощь и поддержка».

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

На виртуальном хостинге все ресурсы сервера делятся между аккаунтами, и каждому выделяется лимит, определенный тарифным планом. Чтобы сервер, который обслуживает тысячи сайтов, работал стабильно, потребление ресурсов на хостинге контролируется.

Процессы

Запросы посетителей к скриптам вашего сайта обрабатывают процессы веб-сервера. Также к процессам относится любое действие, которое совершает пользователь на сервере: подключение к почтовому ящику, FTP или SSH, выполнение задания в планировщике Cron или скрипта в консоли.

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

Как могут проявить себя ограничения:

Нагрузка на CPU

Период времени, в течение которого процессор (CPU) занимается обработкой скриптов сайта, называется процессорным временем. Лимит процессорных секунд зависит от выбранного тарифа.

Отслеживать нагрузку на процессор можно на графиках в Панели управления, там представлены:

Общая нагрузка всеми сайтами на аккаунте
Графики потребления ресурсов процессора (скриптами) и дисковой подсистемы (запросами к серверу БД)
Статистика по количеству и типу запросов к сайтам
Данные о среднесуточном потреблении ресурсов процессора

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

Контроль среднесуточного потребления

Максимально доступный для аккаунта объем ресурсов в сутки можно рассчитать по формуле:

Максимум = CPU (по тарифу) × 1440 (минут в сутках)

Данные наглядно отображены на графике в Панели управления.

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

Если аккаунт превысил допустимую нагрузку, на следующий день к нему автоматически применяются меры, в зависимости от объема и количества превышений:

На 100% — аккаунт блокируется;
На 30% — направляется предупреждение;
Аккаунт виртуального хостинга блокируется с третьим предупреждением, премиум-хостинга — с седьмым.

Письма о превышении лимита и блокировке аккаунта отправляются на контактную почту. Блокировка снимается автоматически при изменении тарифного плана на такой, лимит ресурсов которого соответствует объему, потребляемому аккаунтом на момент блокировки.

Что делать, если ресурсы тарифа превышены?

Чтобы не столкнуться с ошибками на сайте или блокировкой, оптимизируйте сайт:

Отключите неиспользуемые модули
Используйте кеширование
Следите за запросами к сайту
Регулярно проверяйте сайт ХакСканом и удаляйте вредоносный код

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

Читайте также: