Два тарифа хостинга могут выглядеть почти одинаково. Оба позволяют разместить несколько сайтов, предлагают достаточно места на диске, базы данных, SSL и почту. Один при этом работает с WordPress без заметных проблем, а на другом сайт периодически начинает тормозить или получает ошибку именно тогда, когда приходит больше посетителей.
Причина нередко скрывается в характеристиках, которые на странице тарифа выглядят куда менее эффектно, чем десятки гигабайт NVMe. Это лимиты процессора, оперативной памяти, количества одновременно работающих процессов и дисковых операций.
Именно они определяют, сколько реальной работы аккаунт способен выполнить за короткий промежуток времени.
Разобраться в этих ограничениях полезно еще до покупки хостинга. Особенно если размещается WordPress, интернет-магазин или несколько сайтов в одном аккаунте.
Почему на виртуальном хостинге вообще существуют лимиты
Виртуальный хостинг устроен так, что один физический сервер обслуживает множество клиентов. Каждый получает собственный аккаунт и работает в общей серверной инфраструктуре.
Если одному сайту позволить бесконтрольно занять весь процессор или оперативную память, проблемы почувствуют остальные пользователи машины. Поэтому хостеры ограничивают ресурсы аккаунтов и изолируют их друг от друга.
Само наличие лимитов не является недостатком. Наоборот, понятные ограничения помогают предсказать, какую нагрузку выдержит тариф.
Проблема начинается, когда покупатель смотрит только на объем диска и количество разрешенных сайтов. Например, тариф позволяет добавить двадцать доменов. Это не означает, что двадцать тяжелых интернет-магазинов смогут одновременно использовать сервер без ограничений.
Количество сайтов отвечает на вопрос «сколько можно создать». Лимиты ресурсов отвечают на гораздо более важный вопрос «сколько работы они смогут выполнять».
CPU показывает доступную вычислительную мощность
Процессор нужен каждый раз, когда сервер выполняет код. PHP обрабатывает запрос WordPress, плагин формирует страницу, база выполняет часть операций, архив распаковывается, изображение преобразуется, запускается cron.
Провайдеры описывают лимит CPU по-разному. Где-то это процент вычислительной мощности, где-то условные единицы, доля ядра или собственный показатель нагрузки.
Поэтому цифру одного хостинга нельзя автоматически сравнивать с цифрой другого. «100% CPU» в разных системах учета не обязаны означать одинаковый ресурс.
Гораздо полезнее прочитать документацию конкретного провайдера и выяснить две вещи: как измеряется процессорная нагрузка и что происходит после достижения лимита.
Кратковременный пик сам по себе не всегда опасен. Сайт открыли одновременно несколько посетителей, WordPress выполнил работу, нагрузка выросла и быстро вернулась к обычному уровню. Другая ситуация, когда аккаунт регулярно находится около разрешенного предела. Тогда новые запросы начинают конкурировать за CPU, и сайт замедляется.
RAM на хостинге расходует не размер сайта
Иногда оперативную память путают с дисковым пространством. Сайт занимает несколько гигабайт на диске, поэтому кажется, что ему требуется столько же RAM. Между этими показателями нет прямой связи.
В памяти находятся работающие процессы и данные, которые нужны им прямо сейчас.
Один небольшой по размеру сайт способен потреблять много RAM во время тяжелого импорта. Большой статический проект с тысячами файлов может почти не создавать динамической нагрузки.
Для PHP-сайтов память расходуют выполняющиеся процессы. На нее также влияют плагины, административные операции, фоновые задания и особенности конфигурации.
Если лимит памяти аккаунта достигнут, новые процессы могут не получить нужный ресурс. Последствия зависят от устройства хостинга: от замедления до ошибок выполнения.
Не следует путать общий лимит RAM аккаунта с PHP memory_limit. Последний ограничивает память отдельного PHP-процесса или скрипта, а не обязательно весь хостинговый аккаунт.
Количество процессов иногда важнее количества гигабайт
Представим WordPress, который получает несколько динамических запросов одновременно. Каждый запрос должен быть обработан. Если доступных рабочих процессов достаточно, они выполняются параллельно. Если нет, часть запросов вынуждена ждать.
Именно поэтому сайт может тормозить при росте посещаемости, хотя свободного места на диске еще десятки гигабайт.
У разных хостеров можно встретить ограничения на процессы, одновременные PHP-процессы, workers или похожие параметры. Терминология зависит от платформы.
Для полностью закэшированной страницы проблема проявляется слабее, потому что веб-серверу не всегда приходится заново запускать тяжелую обработку CMS. Для личного кабинета, корзины магазина, поиска и других динамических страниц кэширование помогает не во всех сценариях.
Поэтому интернет-магазин с относительно небольшой посещаемостью иногда оказывается требовательнее информационного сайта с большим числом просмотров.
IOPS ограничивает работу с диском
Еще один параметр, который легко пропустить, связан с дисковыми операциями.
Сайту приходится читать и записывать множество небольших файлов, обращаться к данным, создавать кэш, журналы, временные файлы. Количество операций ввода-вывода в единицу времени обычно описывается через IOPS.
Быстрый NVMe дает хостеру производительную физическую основу, но аккаунт виртуального хостинга все равно может иметь собственные ограничения дисковой нагрузки. Это нормально для общей инфраструктуры.
Особенно заметен диск во время резервного копирования, распаковки больших архивов, импорта, обновлений и других массовых операций.
Если сайт замедляется только во время таких задач, покупать тариф исключительно с большим количеством CPU может оказаться бесполезно. Сначала нужно понять, какой именно ресурс достигает предела.
Почему один WordPress работает легко, а другой постоянно упирается в лимиты
Название CMS почти ничего не говорит о реальной нагрузке.
Один WordPress состоит из простой темы, нескольких аккуратных плагинов и хорошо настроенного кэша. Другой использует конструктор страниц, интернет-магазин, фильтры каталога, импорт данных, внешнюю CRM, десятки плагинов и регулярно выполняет фоновые задания.
Формально оба сайта работают на WordPress. Требования к хостингу у них разные.
На нагрузку влияют и действия администратора. Массовая генерация миниатюр, обновление большого каталога или резервное копирование способны создать пик, которого обычные посетители никогда не создают.
Поэтому вопрос «какой лимит CPU нужен WordPress» без описания самого проекта имеет мало смысла.
Лучший ориентир для работающего сайта — собственная статистика потребления ресурсов.
Несколько сайтов используют общий запас аккаунта
Это особенно важно учитывать при выборе тарифа с возможностью разместить много доменов.
Если десять сайтов находятся в одном аккаунте виртуального хостинга, они обычно используют выделенные этому аккаунту ресурсы совместно. Один проблемный проект способен повлиять на соседние сайты владельца.
Например, на одном домене запускается тяжелый импорт. Он занимает процессор и рабочие процессы. В этот момент второй сайт начинает отвечать медленнее, хотя с ним самим ничего не происходило.
То же возможно при атаке на один из сайтов, некорректном плагине или неожиданном всплеске трафика.
Поэтому разрешение разместить «неограниченное количество сайтов» не следует воспринимать как обещание неограниченной производительности. Физические ресурсы всегда конечны.
Для нескольких небольших проектов общий аккаунт удобен. Когда один сайт становится значительно тяжелее остальных, его иногда разумнее вынести отдельно.
Как понять, что сайт упирается именно в тариф
Не нужно ждать, пока сайт окончательно перестанет открываться.
Многие панели показывают статистику потребления CPU, памяти, процессов или других ресурсов. Посмотрите графики не только в спокойное время, но и в момент, когда пользователи жалуются на скорость.
Если один показатель регулярно достигает разрешенного максимума одновременно с замедлением сайта, появляется хорошая зацепка.
Полезно посмотреть и серверные журналы. Ошибки нехватки ресурсов, проблемы PHP и фоновые задачи могут объяснить больше, чем обычный тест скорости страницы.
Если подробная статистика недоступна, напишите в поддержку. Хороший вопрос звучит не «почему у вас тормозит хостинг», а «какой лимит моего аккаунта был достигнут в такое-то время и какой процесс создал нагрузку».
Так поддержке проще дать конкретный ответ.
Когда лучше оптимизировать сайт, а не покупать тариф выше
Достижение лимита еще не означает, что сайту объективно требуется больше ресурсов.
Причиной может быть сломанный плагин, слишком частый cron, бот, который создает тысячи запросов, неоптимальный запрос к базе или резервное копирование, запускаемое в самое загруженное время.
Если просто увеличить тариф, проблема исчезнет на некоторое время, но не обязательно будет решена.
Особенно подозрительно выглядит резкое изменение. Сайт месяцами потреблял небольшую долю ресурсов и внезапно начал постоянно загружать CPU после обновления одного плагина. В такой ситуации логичнее сначала найти причину.
Другое дело, если проект естественно вырос. Посетителей стало больше, каталог расширился, появились личные кабинеты и фоновые процессы. Оптимизация уже выполнена, но рабочая нагрузка стабильно приблизилась к ограничениям тарифа.
Тогда увеличение ресурсов является нормальным этапом развития.
Когда пора смотреть в сторону VPS
Более дорогой тариф виртуального хостинга не всегда является единственным следующим шагом.
VPS становится интересен, когда проекту нужны предсказуемые ресурсы, собственные настройки серверного окружения, нестандартное программное обеспечение или больше контроля над процессами и базой данных.
Но переход на VPS добавляет ответственность. Операционную систему нужно обновлять, сервер защищать, службы настраивать и контролировать. Если этим занимается провайдер в рамках управляемой услуги, условия администрирования стоит проверить отдельно.
Поэтому небольшой сайт не нужно переносить на VPS только потому, что один раз произошел пик CPU.
Сначала определите причину, затем посмотрите возможности текущего хостинга. Иногда переход на следующий тариф решает вопрос проще. Иногда проект действительно вырос из shared hosting.
На какие ограничения смотреть перед покупкой хостинга
Количество гигабайт диска остается важной характеристикой, но для динамического сайта я бы обязательно попыталась найти информацию и о вычислительных лимитах.
- Как учитывается CPU и какой лимит действует на тарифе.
- Есть ли ограничение оперативной памяти аккаунта.
- Сколько процессов или PHP workers может работать одновременно.
- Ограничивается ли дисковый ввод-вывод.
- Есть ли лимиты баз данных, соединений и фоновых задач.
- Где в панели смотреть фактическое потребление ресурсов.
- Что происходит при кратковременном превышении.
- Можно ли быстро перейти на более производительный тариф.
Не все провайдеры публикуют эти параметры одинаково подробно. Если характеристика важна для вашего проекта, ее можно уточнить у поддержки до оплаты.
Именно здесь становится видно различие между «много места за небольшие деньги» и действительно подходящим хостингом.
Безлимитный хостинг тоже имеет предел
Слово «безлимитный» обычно относится к конкретной характеристике. Например, провайдер может не устанавливать жесткий предел количества сайтов или трафика.
Это не отменяет ограниченность процессора, памяти, дисковой системы и самой физической инфраструктуры.
Если на тарифе разрешено сколько угодно доменов, тысяча тяжелых интернет-магазинов все равно не превращается в реалистичный сценарий.
Поэтому условия безлимитного тарифа нужно читать полностью. Часто настоящая граница находится не там, где ее первым делом ищет покупатель.
Для небольшого сайта это не повод бояться виртуального хостинга. Наоборот, shared hosting остается удобным вариантом, когда проект укладывается в предусмотренную модель нагрузки и владельцу не хочется заниматься сервером.
Важно лишь понимать, что вы покупаете не просто гигабайты диска. Вы покупаете возможность сайта выполнять определенный объем работы на общей серверной платформе.
Хороший тариф тот, лимиты которого соответствуют реальной нагрузке
Не существует одного идеального значения CPU, RAM или количества процессов для всех сайтов.
Лендинг, блог, интернет-магазин и несколько WordPress-проектов создают разную нагрузку. Даже два внешне похожих магазина могут отличаться из-за плагинов, числа товаров, импорта и поведения посетителей.
Поэтому для нового проекта разумно выбирать хостинг с понятными условиями и возможностью перейти выше без сложного переезда. Для уже работающего сайта главным источником информации становятся собственные графики нагрузки.
Если сайт стабильно далек от лимитов, покупать дополнительные ресурсы «на всякий случай» не нужно. Если ограничения достигаются регулярно, сначала выясните причину. И только после этого решайте, поможет оптимизация, следующий тариф виртуального хостинга или уже пора переходить на VPS.
Так выбор хостинга перестает быть сравнением количества гигабайт и превращается в более полезный вопрос: сколько реальной серверной работы требуется вашему сайту и где он сможет выполнять ее без постоянной борьбы с ограничениями.
