На диске свободно еще 20 ГБ, месячный трафик даже близко не подошел к заявленному пределу, посетителей не так уж много, а сайт вечером начинает открываться заметно медленнее. Иногда панель хостинга присылает предупреждение о превышении нагрузки, иногда появляются 503 или 508, а иногда внешне ничего не ломается, просто каждая динамическая страница думает дольше обычного. В такой момент владелец сайта чаще всего смотрит на самый понятный показатель, количество свободного места, и искренне не понимает, чего серверу еще не хватает.
Проблема в том, что гигабайты на диске лишь один из множества ресурсов. Виртуальный хостинг ограничивает не только объем файлов. Сайт использует процессорное время, оперативную память, дисковые операции, PHP-процессы, соединения с базой, количество файлов и другие ресурсы. Даже тариф с «неограниченным трафиком» физически работает на конечном сервере, где вычислительная мощность делится между клиентами.
Именно поэтому два сайта одинакового размера могут вести себя совершенно по-разному. Один представляет собой хорошо кэшируемый блог, где посетитель получает почти готовую страницу. Другой при каждом открытии запускает тяжелый PHP-код, выполняет множество запросов к базе, обращается к внешним сервисам и генерирует изображения. На диске оба занимают по 3 ГБ, но нагрузка на хостинг у них несопоставима.
Разобраться в лимитах полезно не только тогда, когда сайт уже начал падать. Это помогает правильно читать тарифы, не переплачивать за ненужные гигабайты и понимать, когда действительно пора переходить на более мощную площадку, а когда проблема решается оптимизацией самого проекта.
Что на самом деле ограничивает виртуальный хостинг
Виртуальный хостинг устроен по принципу совместного использования инфраструктуры. На одном физическом сервере работают аккаунты разных клиентов, поэтому провайдер должен следить, чтобы один сайт не занял все ресурсы. Иначе один неудачный импорт товаров или зацикленный скрипт мог бы замедлить сотни чужих проектов.
Отсюда и появляются лимиты. Они не являются скрытым наказанием клиента, а служат способом разделить общую мощность сервера. Вопрос в том, насколько прозрачно провайдер их описывает и соответствуют ли они вашему типу сайта.
Если хочется понять саму модель подробнее, полезно знать, как работает shared-хостинг. Главное здесь другое: слово «виртуальный» не означает, что ресурсы бесконечны. Вы арендуете часть общей системы и работаете в пределах установленной политики.
На тарифной странице крупными цифрами обычно показывают то, что проще сравнивать: 10, 20 или 50 ГБ диска, количество сайтов, почтовых ящиков, баз данных. CPU, RAM, I/O и процессы часто находятся ниже, в отдельной таблице или документации. Но именно они могут определить, выдержит ли тариф магазин на WooCommerce или только небольшой блог.
У одного провайдера процессорная нагрузка выражается в процентах, у другого в секундах CPU за сутки, у третьего в условных единицах. Память может ограничиваться на весь аккаунт или на процесс. Количество одновременно работающих PHP-процессов тоже бывает разным. Поэтому невозможно взять два тарифа и сравнить одну цифру «CPU 100%» с другой «CPU 2000 секунд». Нужно понимать методику конкретной площадки.
Отдельно существуют мягкие ограничения. Провайдер может не выключать сайт мгновенно при кратком превышении, но если нагрузка становится постоянной, аккаунт ограничивается. Именно поэтому сайт иногда спокойно переживает короткий всплеск, а затем начинает тормозить во время длительной активности.
CPU: почему процессор заканчивается первым, хотя посетителей немного
CPU отвечает за вычисления. На динамическом сайте процессор выполняет PHP, часть операций базы данных, обработку шаблонов, генерацию страниц, фоновые задачи и множество служебных операций.
Количество посетителей само по себе почти ничего не говорит о процессорной нагрузке. Один человек способен открыть страницу, которую сервер отдает из кэша за доли секунды. Другой запускает поиск по каталогу, применяет фильтры и вызывает тяжелую цепочку SQL-запросов. Формально посетителей двое, а нагрузка отличается в десятки раз.
У WordPress CPU часто съедают плагины. Причем количество расширений не является надежным показателем. Двадцать простых плагинов могут работать легче одного неудачного конструктора, статистического модуля или фильтра товаров. Важна не цифра в разделе «Плагины», а то, какой код выполняется при каждом запросе.
Есть еще фоновые процессы. Резервное копирование, генерация миниатюр, импорт каталога, обновление поискового индекса, Cron и массовая отправка писем способны временно занять значительную часть CPU. Если такая задача запускается ночью, владелец может вообще не замечать проблему. Если она совпадает с вечерним пиком посещаемости, сайт начинает медленно отвечать именно тогда, когда посетителей больше всего.
Характерный симптом нехватки CPU выглядит так: диск свободен, память не обязательно заполнена, но динамические страницы начинают отвечать медленнее, а в панели нагрузки процессор регулярно достигает предела. Если это происходит только на определенных страницах, стоит искать тяжелую операцию. Если вся система замедляется одновременно, проблема шире.
Не следует автоматически считать высокий CPU недостатком тарифа. Сначала важно понять, полезная ли это нагрузка. Если сайт получил в три раза больше реальных посетителей, переход на более мощный план логичен. Если процессор съедает ошибочный цикл в плагине, покупка дополнительных ресурсов лишь сделает этот цикл дороже.
Проверять процессорную часть лучше вместе с серверным временем ответа. В отдельном материале о скорости сервера сайта подробно разобрано, почему медленный TTFB и медленная полная загрузка страницы не одно и то же. Для лимитов это особенно важно: если сервер отвечает быстро, а браузер долго загружает фотографии и JavaScript, CPU хостинга может быть вообще ни при чем.
RAM, PHP memory_limit и процессы: три разных ограничения, которые часто путают
Оперативная память используется работающими процессами. В ней находятся данные приложения, кэш, часть информации базы, PHP-процессы и другие компоненты серверного окружения. Когда RAM не хватает, система вынуждена действовать жестче: ограничивать процессы, использовать swap там, где он доступен, или завершать наиболее ресурсоемкие задачи.
На shared-хостинге пользователь часто не видит всю память физического сервера. Его интересует квота аккаунта или конкретного процесса. Здесь появляется первая путаница. В настройках PHP можно увидеть memory_limit, например 256 МБ или 512 МБ, и решить, что именно столько памяти есть у сайта. Это неверно.
memory_limit ограничивает потребление отдельного PHP-скрипта. Одновременно может выполняться несколько PHP-процессов, работать база данных, служебные процессы и другие компоненты. Поэтому VPS с 4 ГБ RAM и PHP memory_limit 256 МБ не является противоречием.
Есть и третья величина, число одновременно работающих процессов. Допустим, каждый PHP-процесс потребляет умеренно, но сайт получил много параллельных динамических запросов. Если тариф разрешает только ограниченное количество workers, новые запросы будут ждать освобождения процесса. Пользователь видит задержку, хотя каждый отдельный запрос сам по себе не очень тяжелый.
Это особенно заметно у магазинов, личных кабинетов и сайтов с авторизованными пользователями. Статический блог способен отдавать огромную часть трафика из кэша. Корзина, оформление заказа, личный кабинет и персонализированные страницы кэшируются намного сложнее и требуют полноценной серверной обработки.
Нехватка памяти часто проявляется ошибками вроде «Allowed memory size exhausted» в PHP error log. А нехватка процессов может выглядеть как очереди и внезапные задержки во время одновременной активности. Эти случаи внешне похожи, но исправляются по-разному.
Если один плагин требует слишком высокий memory_limit только для выполнения обычной страницы, сначала стоит разобраться с плагином. Если памяти стабильно не хватает из-за реальной нагрузки нескольких сайтов, более высокий тариф уже выглядит разумно.
I/O и IOPS: почему быстрый NVMe может внезапно оказаться медленным
Дисковая подсистема отвечает не только за то, сколько данных можно хранить, но и за то, насколько быстро сервер может их читать и записывать. Именно здесь появляются I/O и IOPS.
I/O обычно описывает скорость передачи данных при операциях ввода-вывода. IOPS отражает количество операций, которые система способна выполнить за определенное время. Для сайта обе характеристики могут иметь значение. Большой последовательный файл и тысячи маленьких файлов создают совершенно разный профиль нагрузки.
Представим два проекта. Первый раз в минуту читает один крупный файл. Второй постоянно обращается к множеству мелких файлов кэша, пишет логи и работает с базой. Даже при одинаковом объеме переданных данных второй создает больше отдельных операций.
Именно поэтому надпись «NVMe» в тарифе не означает безлимитную дисковую производительность. Физический накопитель может быть очень быстрым, но аккаунту выделяется ограниченная доля I/O. Это нормальная практика на общей платформе.
Упор в I/O встречается при резервном копировании, массовой распаковке архивов, генерации изображений, активной записи логов, больших импортных операциях и некоторых сценариях работы базы. Сайт может казаться медленным, хотя CPU не находится на максимуме.
Владельцу обычного сайта необязательно разбираться в устройстве очередей диска. Достаточно понимать симптом: если тормоза появляются именно во время активного чтения или записи файлов, стоит посмотреть показатели I/O. Если хостинг показывает такой график, он может сразу объяснить странные замедления во время бэкапа.
Отдельно стоит помнить, что свободное дисковое пространство и скорость диска никак не взаимозаменяемы. 80 ГБ свободного места не помогут, если аккаунт упирается в I/O. Так же и более быстрый диск не заменяет CPU.
Inode и количество файлов: невидимый потолок при свободных гигабайтах
Еще одна характеристика, которую владельцы замечают обычно слишком поздно, это количество файлов и объектов файловой системы. На хостинге такой лимит часто называют inode.
Представим тариф на 50 ГБ. Сайт занимает только 12 ГБ, поэтому кажется, что пространства огромный запас. Но WordPress создал множество миниатюр, кэш плодит тысячи мелких файлов, почта хранится в отдельных объектах, а система резервного копирования распаковывает временные данные. В какой-то момент лимит inode заканчивается раньше, чем гигабайты.
После этого возникают странные симптомы. Нельзя загрузить новый файл, не создается кэш, обновление CMS завершается ошибкой, почта перестает принимать сообщения. В панели при этом по-прежнему написано, что десятки гигабайт свободны.
Именно поэтому при выборе тарифа важно смотреть не только на диск. В статье о том, сколько места нужно сайту на хостинге, отдельно разбирается разница между объемом данных и количеством файлов.
Если inode заканчиваются, не нужно сразу покупать в два раза больше диска. Сначала посмотрите, что создает огромное количество объектов. Иногда виноват забытый кэш, временные файлы или старые резервные копии. После уборки лимит снова становится комфортным.
Но если сам проект объективно состоит из миллионов мелких файлов, тариф должен учитывать эту специфику. Увеличение только дискового пространства здесь бессмысленно.
Как понять, во что именно уперся сайт
Самая полезная привычка при проблемах с ресурсами, не пытаться угадывать по ощущениям. Нужно сопоставлять симптомы со статистикой.
Если сайт медленно работает только при динамических запросах, а CPU постоянно на пределе, первым подозреваемым становится процессорная нагрузка. Если в журнале появляются сообщения о нехватке памяти, проверяется RAM и memory_limit. Если задержки совпадают с резервным копированием или импортом и график I/O достигает потолка, вероятнее дисковое ограничение. Если невозможно создавать новые файлы при свободном диске, смотрят inode.
Количество PHP-процессов особенно важно при параллельной нагрузке. Сайт может быстро обрабатывать один запрос, но резко замедляться, когда одновременно приходит несколько пользователей. Это не обязательно означает, что сам код медленный. Возможно, запросы просто выстраиваются в очередь.
Полезно смотреть на время. Допустим, сайт стабильно тормозит каждый день с 02:00 до 02:20. Посещаемость в это время минимальная. Вряд ли виноваты покупатели. Скорее именно тогда запускается бэкап, Cron или импорт. Регулярность дает гораздо больше информации, чем общий график «вчера CPU был высокий».
Другая ситуация: нагрузка выросла после рекламной кампании и падает вместе с количеством посетителей. Здесь уже есть связь с реальным трафиком.
Провайдеры часто показывают средние значения, а проблема возникает коротким пиком. Поэтому по возможности полезно смотреть график с небольшим интервалом, а не только суточное среднее. Пять минут на пределе способны испортить впечатление от сайта, хотя средний CPU за сутки выглядит совершенно спокойным.
Если панель не дает нужной статистики, поддержку можно попросить назвать конкретный лимит и сообщить, какой параметр был превышен в определенное время. Такой вопрос намного полезнее, чем «почему сайт тормозит?».
Оптимизировать сайт или покупать более мощный тариф
Это главный практический вопрос. Иногда ответ очевиден. Если проект вырос, посетителей стало больше, заказов больше, а текущий тариф стабильно находится у потолка, ресурсы действительно нужно увеличивать. Но не каждый перегруженный сайт заслуживает более дорогой сервер.
Сначала стоит проверить простые причины. Не выполняется ли слишком тяжелый код? Не запускается ли Cron каждую минуту без необходимости? Не делает ли плагин резервного копирования архив каждые полчаса? Не создают ли боты тысячи динамических запросов? Не выключен ли кэш? Не выросли ли журналы из-за постоянной ошибки?
Хорошая оптимизация не означает бесконечную экономию. Нет смысла неделями переписывать рабочий магазин только ради того, чтобы оставаться на самом дешевом тарифе. Если проект приносит деньги и объективно требует больше ресурсов, нормальный запас полезнее постоянной борьбы с потолком.
С другой стороны, покупка мощного VPS для исправления одного неудачного плагина тоже выглядит странно. Неэффективный код способен съесть любое количество ресурсов, просто на более дорогом сервере это произойдет позже.
Полезно ориентироваться не на единичный пик, а на регулярное состояние. Тариф должен выдерживать обычную нагрузку с запасом и переживать разумные кратковременные всплески. Если сайт каждый вечер работает на 95-100 процентах доступного CPU, запаса уже нет. Если предел достигается раз в неделю на две минуты во время служебной задачи, срочное масштабирование может не понадобиться.
Когда shared-хостинг действительно перестает подходить, можно рассматривать VPS. Но переход дает не только больше контроля, он переносит на владельца или администратора новые обязанности. Поэтому перед миграцией полезно понять, что меняется при переходе с виртуального хостинга на VPS/VDS.
Как выбирать тариф, если теперь вы знаете про лимиты
После знакомства с CPU, RAM, I/O и inode тарифная таблица начинает выглядеть иначе. Большой диск больше не воспринимается как универсальный признак мощности, а слово «безлимит» хочется сразу уточнить: безлимит чего именно?
Для небольшого информационного сайта важен достаточный запас CPU и процессов, но очень высокие значения могут никогда не понадобиться. Магазину и динамическому проекту стоит внимательнее смотреть на CPU, RAM и одновременные процессы. Сайт с огромным количеством фотографий требует не только диска, но и понимания inode. Проект с частыми импортами и большими архивами может сильнее зависеть от I/O.
Сравнивать тарифы разных провайдеров непросто, потому что лимиты описываются разными методами. Поэтому хорошая документация сама по себе является преимуществом. Если компания четко публикует ограничения и объясняет, что происходит при их превышении, пользователю проще прогнозировать поведение проекта.
Перед покупкой стоит выяснить, насколько легко перейти на следующий тариф, можно ли сделать это без переноса сайта, как учитывается уже оплаченный период и какие ограничения меняются вместе с апгрейдом. Иногда соседний тариф увеличивает только диск, тогда как проблема сайта находится в CPU. Такой переход ничего не решит.
Для нового проекта нет необходимости заранее покупать огромный запас. Гораздо важнее выбрать площадку, где ресурсы можно увеличить без болезненной миграции. Подробный подход к оценке тарифа разобран в материале о том, как выбрать хостинг для сайта.
А если сайт уже работает и периодически достигает границ тарифа, не нужно ждать первой серьезной недоступности. Сохраните показатели за неделю, посмотрите время пиков, определите тип ресурса и только после этого решайте, что выгоднее: оптимизация, следующий тариф или собственный виртуальный сервер.
Лимит сам по себе не проблема, если вы знаете, где он находится
У любого хостинга есть предел. У shared-площадки он ниже и строже разделен между клиентами. У VPS ресурсы выделены понятнее, но все равно конечны. Даже выделенный физический сервер когда-нибудь упрется в процессор, память, диск или сеть.
Поэтому задача не в том, чтобы найти «хостинг без лимитов». Такого не существует. Задача в том, чтобы ресурсы соответствовали проекту, а ограничения были понятными.
CPU отвечает за вычисления. RAM нужна работающим процессам и данным. I/O и IOPS определяют возможности дисковой подсистемы. PHP-процессы влияют на количество одновременно обслуживаемых динамических запросов. Inode ограничивает число файлов и объектов. Дисковая квота показывает только объем хранения и не заменяет все остальные характеристики.
Если сайт начал тормозить, сначала определите, какой ресурс находится у потолка. Затем выясните, почему. Реальный рост аудитории и неудачный плагин требуют разных решений. Пиковая нагрузка раз в месяц и ежедневная работа на пределе тоже не одно и то же.
Самый разумный тариф не тот, где написано максимальное число гигабайт, а тот, который дает сайту достаточный запас именно по используемым ресурсам. И если показатели можно посмотреть в панели, а правила провайдера написаны понятным языком, большая часть «загадочных тормозов» перестает быть загадкой еще до обращения в поддержку.
