- Опубликовано: 24 июл 2026
- 16
«Безлимитный» хостинг: что заканчивается раньше дискового пространства
Часть 4 из 14 · Серия «Хостинг без магии»
В описании тарифа написано:
Неограниченный диск
Неограниченный трафик
Неограниченное количество сайтов
Неограниченные базы данных
Неограниченная почта
Кажется, что вопрос выбора хостинга решён навсегда.
Можно разместить сколько угодно проектов, загрузить любой объём изображений, создать сотни почтовых ящиков и не думать о переходе на более дорогой тариф.
Через несколько месяцев владелец получает уведомление:
Ваш аккаунт создаёт повышенную нагрузку на сервер. Просим оптимизировать сайт или перейти на другой тариф.
Пользователь открывает панель. Диск занят всего на 14 ГБ. Трафик тоже не выглядит огромным. До обещанного «безлимита» ещё далеко.
Но сайт регулярно использует все доступные PHP-процессы. Фоновый импорт запускается слишком часто. В почте накопилось несколько сотен тысяч небольших файлов, а резервные копии создаются прямо внутри аккаунта.
Ни один из этих параметров не назывался «дисковым пространством». Однако именно они стали реальным пределом тарифа.
Физически неограниченных серверов не существует.
У любого хостинга конечны:
- процессор;
- оперативная память;
- накопители;
- число операций с диском;
- сетевые каналы;
- количество процессов;
- соединения с базой;
- рабочее время специалистов;
- место в резервном хранилище.
Поэтому слово «безлимитный» обычно означает не отсутствие ограничений вообще, а отсутствие одного простого фиксированного числа в рекламной таблице.
Главный вопрос звучит так:
Какое ограничение применяется вместо заявленного безлимита?
Что обычно означает «безлимитный»
В зависимости от услуги безлимит может означать несколько разных моделей.
Нет заранее установленной квоты
В тарифе не указано:
10 ГБ диска
500 ГБ трафика
20 почтовых ящиков
Пользователь может расти, пока его потребление остаётся обычным для сайтов этого класса и не мешает работе сервера.
Это модель допустимого или разумного использования.
Ресурс ограничен не объёмом, а назначением
Провайдер может разрешать хранить любое разумное количество файлов сайта, но запрещать использовать аккаунт как:
- файловый архив;
- облачный диск;
- резервное хранилище;
- торрент-сервер;
- видеохостинг;
- публичное зеркало;
- площадку для распространения крупных файлов.
То есть место формально не ограничено числом, но использовать его можно только для работы сайтов.
Ограничение существует на другом уровне
Например, диск заявлен как безлимитный, но действуют:
500 000 файлов
20 МБ/с дискового ввода-вывода
20 PHP-процессов
2 ГБ оперативной памяти
200% CPU
Пользователь теоретически может хранить много крупных файлов, но миллионы мелких файлов уже не поместятся из-за inode.
Лимит определяется текущим тарифом и политикой нагрузки
Провайдер может не устанавливать жёсткую квоту, но оставлять за собой право ограничить аккаунт, который:
- постоянно использует слишком много CPU;
- создаёт чрезмерную дисковую нагрузку;
- мешает другим клиентам;
- выполняет задачи, не соответствующие обычному хостингу;
- хранит несвязанные с сайтами данные;
- отправляет массовую почту;
- создаёт слишком много процессов.
В таком случае реальный предел находится не в таблице тарифа, а в правилах оказания услуги.
Безлимит не равен бесконечному ресурсу
Представим ресторан с безлимитным напитком.
Посетитель может несколько раз наполнить стакан во время обеда. Но это не означает, что он может:
- приехать с цистерной;
- разлить напиток по бутылкам для перепродажи;
- перекрыть автомат на весь день;
- использовать ресторан как склад.
Безлимит работает внутри предполагаемого сценария использования.
С хостингом похожая ситуация.
Провайдер рассчитывает, что обычный сайт:
- периодически использует PHP;
- хранит контент;
- получает посещения;
- отправляет ограниченное количество писем;
- создаёт кэш;
- выполняет фоновые задачи;
- не загружает все ресурсы сервера круглосуточно.
Когда аккаунт превращается в постоянную вычислительную задачу или файловое хранилище, он выходит за рамки модели виртуального хостинга.
Где искать настоящий предел
Информация об ограничениях может находиться в нескольких местах:
- таблице тарифов;
- подробном описании услуги;
- технических характеристиках;
- справочном центре;
- договоре;
- правилах допустимого использования;
- политике нагрузки;
- правилах почтовой отправки;
- условиях резервного копирования;
- ответах технической поддержки.
Если на главной странице написано только «всё без ограничений», этого недостаточно для принятия решения.
До оплаты нужно найти ответы хотя бы на такие вопросы:
Как ограничивается CPU?
Сколько доступно оперативной памяти?
Сколько разрешено PHP-процессов?
Есть ли лимит inode?
Как ограничены I/O и IOPS?
Какой размер базы данных допустим?
Сколько соединений с базой разрешено?
Какие лимиты почтовой отправки?
Что считается недопустимым использованием?
Что происходит при превышении?
Безлимитный диск: что это может значить
Дисковое пространство — один из самых популярных безлимитов.
Обычно предложение выглядит так:
Размещайте сайты без ограничений по объёму.
Но одновременно могут действовать другие условия.
Файлы должны относиться к работающему сайту
Разрешены:
- код;
- изображения;
- документы сайта;
- база;
- кэш;
- логи;
- пользовательские загрузки;
- почта.
Могут быть запрещены:
- личный фотоархив;
- резервные копии компьютера;
- коллекция фильмов;
- ISO-образы;
- архивы сторонних проектов;
- файлы, не используемые сайтом;
- публичная раздача больших объектов.
Такое ограничение связано не только с объёмом, но и с назначением услуги.
Виртуальный хостинг предназначен для размещения сайтов, а не для замены универсального облачного хранилища.
Может существовать лимит размера одного файла
Например, общий объём не ограничен, но нельзя загрузить файл больше:
2 ГБ
5 ГБ
10 ГБ
Ограничение может исходить из:
- файловой системы;
- панели;
- PHP;
- FTP;
- прокси;
- правил тарифа.
Для обычного сайта это почти незаметно. Для видеоархива или больших резервных копий становится критичным.
Может ограничиваться число файлов
Диск без фиксированной квоты не отменяет inode.
Аккаунту могут разрешить, например:
500 000 файлов и каталогов
Если каждый объект занимает в среднем 20 КБ, теоретический объём составит около 10 ГБ.
Если каждый файл занимает 100 МБ, тот же лимит позволит хранить десятки терабайт — хотя на практике сработают другие ограничения.
Поэтому безлимитный диск и лимит inode не противоречат друг другу.
Что заканчивается первым: inode
Современные сайты создают огромное количество небольших файлов.
Особенно быстро inode расходуют:
node_modules;- Composer-пакеты;
- кэш;
- файловые сессии;
- миниатюры;
- почтовые сообщения;
- резервные копии;
- старые релизы;
- временные файлы;
- заражённые скрипты;
- логи, разбитые по датам.
Пример аккаунта:
5 сайтов 120 000 файлов
почта 180 000 файлов
node_modules 90 000 файлов
старые кэши 60 000 файлов
резервные копии 40 000 файлов
Итого:
490 000 файлов
На диске может быть занято всего 12 ГБ, но при лимите 500 000 inode аккаунт практически заполнен.
Симптомы:
- не загружаются новые изображения;
- не создаются сессии;
- не обновляется CMS;
- перестают приниматься письма;
- не записываются логи;
- Composer завершается ошибкой;
- невозможно распаковать архив.
Покупка дополнительных гигабайт не поможет, если не увеличивается лимит файлов.
Безлимитный трафик
Неограниченный трафик обычно означает отсутствие фиксированной месячной квоты:
500 ГБ в месяц
1 ТБ в месяц
Провайдер не считает каждый переданный гигабайт отдельно либо не выставляет доплату после определённого объёма.
Но другие ограничения остаются.
Скорость порта
Аккаунт или сервер может использовать соединение:
до 100 Мбит/с
до 1 Гбит/с
Безлимитный объём не означает бесконечную скорость.
Если канал ограничен 100 Мбит/с, теоретически за месяц можно передать большой объём данных. Но одновременная загрузка множества крупных файлов всё равно упрётся в скорость порта.
Политика постоянной нагрузки
Провайдер может разрешать кратковременное использование высокой скорости, но ограничивать постоянную передачу на максимуме.
Например, сайт может пережить всплеск скачиваний, но не должен круглосуточно работать как файловое зеркало.
Запрет отдельных сценариев
Даже при безлимитном трафике могут быть запрещены:
- видеостриминг;
- торрент-трекеры;
- публичные прокси;
- CDN для сторонних ресурсов;
- массовая раздача архивов;
- сервисы обхода блокировок;
- постоянное резервное копирование внешних серверов.
CPU может закончиться раньше трафика
Динамический сайт генерирует каждую страницу через PHP и базу.
Даже если месячный трафик не ограничен, несколько тысяч тяжёлых запросов могут исчерпать:
- CPU;
- PHP-процессы;
- память;
- соединения с базой.
Безлимитный трафик говорит только об объёме переданных данных. Он не гарантирует способность приложения обработать любое количество запросов.
Безлимитное количество сайтов
В панели можно создать сколько угодно доменов.
Это означает лишь отсутствие фиксированного числа:
1 сайт
10 сайтов
50 сайтов
Все проекты продолжают использовать общий пул ресурсов аккаунта.
Представим тариф:
неограниченные сайты
20 PHP-процессов
2 ГБ памяти
200% CPU
Можно разместить:
- сто статических страниц;
- двадцать небольших сайтов-визиток;
- несколько блогов;
- один тяжёлый магазин.
Но разместить сто активно посещаемых магазинов только потому, что домены не ограничены, не получится.
Один сайт может использовать весь тариф
Количество проектов не показывает их сложность.
Один интернет-магазин может потреблять больше ресурсов, чем пятьдесят лендингов.
Поэтому правильный вопрос:
Сколько сайтов такого типа выдержит тариф при их реальной нагрузке?
Без измерений точного ответа не будет.
Безопасность тоже имеет предел
Если все сайты работают:
- в одном аккаунте;
- от одного пользователя;
- с общими правами;
- в одном файловом пространстве,
уязвимость одного проекта может создать угрозу для остальных.
Неограниченное количество доменов не гарантирует изоляцию.
Для клиентских проектов иногда важнее отдельные аккаунты, чем возможность добавить ещё один сайт в общий каталог.
Безлимитные базы данных
Создать можно много баз, но каждая из них использует общий сервер базы данных.
Количество баз не определяет:
- скорость SQL;
- допустимый объём;
- число соединений;
- память;
- время запроса;
- дисковую производительность.
Можно создать сто пустых баз и почти не использовать ресурсы.
Одна большая база с тяжёлыми запросами способна создать значительную нагрузку.
Может ограничиваться размер одной базы
Например:
базы без ограничения по количеству
максимальный объём одной базы — 2 ГБ
Или ограничение может быть сформулировано как разумный объём для тарифа.
Может ограничиваться число соединений
Даже при неограниченном количестве баз сервер может разрешать:
20 одновременных соединений
При превышении появятся ошибки:
Too many connections
или:
User has more than max_user_connections active connections
Может ограничиваться время запросов
Тяжёлый SQL способен быть остановлен либо замедлить другие сайты.
Базы данных на виртуальном хостинге предназначены для обычных веб-приложений, а не для:
- аналитических хранилищ;
- длительных вычислений;
- обработки миллиардов строк;
- бесконечных полнотекстовых индексаций;
- больших отчётов без оптимизации.
Безлимитная почта
Под безлимитной почтой могут подразумеваться:
- неограниченное количество ящиков;
- отсутствие фиксированного размера каждого ящика;
- почта в пределах общего дискового пространства.
Но почтовая система почти всегда имеет дополнительные правила.
Ограничение исходящих сообщений
Для защиты репутации сервера могут действовать лимиты:
100 писем в час
500 писем в сутки
определённое число получателей
Эти ограничения особенно важны для:
- интернет-магазинов;
- форумов;
- CRM;
- массовых уведомлений;
- рассылок;
- восстановления паролей;
- подтверждения регистрации.
Обычная почта сайта и массовый маркетинг — разные сценарии.
Для рассылок часто нужен специализированный сервис.
Ограничение размера письма
Почтовый ящик может быть безлимитным, но одно письмо не должно превышать:
25 МБ
50 МБ
Причём ограничение действует не только у отправителя, но и у получателя.
Почта расходует inode
Каждое сообщение обычно хранится отдельным файлом.
Сто тысяч небольших писем могут занимать мало гигабайт, но много inode.
Особенно быстро растут:
- спам;
- корзина;
- отправленные;
- автоматические уведомления;
- почтовые логи;
- дубли писем в нескольких папках.
Безлимитный ящик не гарантирует резервное копирование
Даже если место не ограничено, нужно отдельно выяснить:
- копируется ли почта;
- как долго хранятся копии;
- можно ли восстановить один ящик;
- учитывается ли почта в общем бэкапе;
- что происходит после удаления сообщения.
Как это устроено на Siteko. Отправка почты с хостинга по умолчанию выключена: на платных тарифах она включается по запросу в поддержку, на пробном периоде отправка недоступна. Это сознательное решение, а не скрытый лимит: репутация IP-адресов сервера — общая для всех клиентов, и один спамящий скрипт способен отправить письма соседей в спам. После включения обычная деловая переписка и служебные письма сайта работают штатно, а для массовых рассылок в любом случае нужен специализированный сервис.
Процессор закончится раньше диска
Диск хранит данные. CPU обрабатывает запросы.
Обычный сайт способен занимать всего 2 ГБ, но постоянно использовать процессор из-за:
- тяжёлого плагина;
- неоптимального кода;
- ботов;
- поиска;
- импорта;
- генерации страниц;
- обработки изображений;
- вредоносного скрипта;
- слишком частого cron;
- отсутствия кэширования.
В результате провайдер может ограничить сайт, хотя дисковый безлимит почти не использован.
Кратковременный пик и постоянная нагрузка
Многие тарифы допускают кратковременное высокое использование ресурсов.
Например:
обновление CMS
импорт
утренний пик посещаемости
генерация миниатюр
Но постоянные 100% CPU означают, что аккаунт регулярно потребляет значительную часть общего сервера.
Виртуальный хостинг рассчитан на переменную веб-нагрузку, а не на круглосуточные вычисления.
Что считается постоянной нагрузкой
У каждого провайдера свои критерии.
Это может быть:
- превышение в течение нескольких минут;
- высокая средняя нагрузка за сутки;
- повторяющиеся пики;
- влияние на соседние аккаунты;
- длительное выполнение фонового процесса;
- использование сверх определённой доли ядра.
Точное правило следует искать в технических условиях.
Закончится оперативная память
Безлимитный диск не означает безлимитную RAM.
Память используют:
- PHP-процессы;
- cron;
- Composer;
- Node.js;
- обработка изображений;
- импорты;
- фоновые команды;
- пользовательские скрипты.
При нехватке памяти возможны:
Allowed memory size exhausted
JavaScript heap out of memory
Killed
Пользователь может видеть свободные гигабайты диска и одновременно не иметь возможности выполнить composer install или собрать frontend.
Общий лимит и лимит одного процесса
Нужно различать:
общая память аккаунта
PHP memory_limit
лимит CLI-команды
лимит Node.js
Высокий memory_limit одного скрипта не увеличивает общую память тарифа.
Если несколько процессов одновременно приблизятся к максимуму, общий лимит закончится раньше.
Закончатся PHP-процессы
Сайт может хранить неограниченное количество файлов, но обрабатывать только ограниченное число динамических запросов одновременно.
Например:
10 PHP workers
Если каждый запрос выполняется быстро, этого может хватать для значительной посещаемости.
Если один запрос занимает десять секунд, десять посетителей займут все процессы, а остальные будут ждать.
Причиной могут быть:
- медленная база;
- внешний API;
- блокировка;
- тяжёлый код;
- отправка почты внутри запроса;
- генерация большого отчёта;
- импорт через браузер.
При этом CPU может быть загружен не полностью: процессы просто ждут внешнюю систему.
Закончится дисковая производительность
Безлимитное место не означает безлимитную скорость записи и чтения.
Аккаунт может быть ограничен по:
- МБ/с;
- IOPS;
- числу одновременных операций;
- времени работы с диском.
Особенно заметно это при:
- архивации;
- резервном копировании;
- установке Composer;
- работе
node_modules; - генерации миниатюр;
- большом файловом кэше;
- интенсивной почте;
- импорте базы;
- множестве сессий.
Большой архив сайта способен копироваться быстро, а тот же объём в виде сотен тысяч мелких файлов — очень медленно.
Закончится время выполнения
Тариф может разрешать сколько угодно сайтов и трафика, но останавливать PHP-скрипт через:
60 секунд
120 секунд
300 секунд
Это влияет на:
- импорт;
- экспорт;
- обработку изображений;
- генерацию отчётов;
- резервное копирование;
- обновление CMS;
- интеграции;
- массовые операции.
Не каждую задачу следует лечить увеличением тайм-аута.
Длительные операции лучше:
- делить на части;
- запускать через cron;
- выполнять очередью;
- переносить в CLI;
- обрабатывать пакетами;
- выносить в отдельный сервис.
Закончится число одновременных процессов
Кроме PHP workers может существовать общий лимит процессов аккаунта.
В него могут входить:
- PHP;
- cron;
- SSH;
- Composer;
- Node.js;
- фоновые скрипты;
- служебные команды.
Представим:
лимит — 30 процессов
20 заняты PHP
5 выполняют cron
1 запускает Composer
4 используются другими командами
Новый процесс уже не запустится.
Именно поэтому тяжёлый cron и frontend-сборка способны повлиять на открытие сайта, даже если выполняются не через браузер.
Закончится допустимое число заданий cron
В таблице может быть написано:
cron без ограничений
Но реальными ограничителями остаются:
- минимальный интервал;
- число процессов;
- время выполнения;
- память;
- CPU;
- параллельный запуск;
- допустимая нагрузка.
Если задача запускается каждую минуту и работает пять минут, вскоре одновременно выполняются пять копий.
Без блокировки:
flock -n /tmp/import.lock php import.php
фоновые задачи начинают конкурировать друг с другом и с посетителями сайта.
Закончится лимит резервных копий
Безлимитный хостинг не означает бесконечную историю бэкапов.
Обычно ограничены:
- число точек восстановления;
- срок хранения;
- частота;
- объём одной копии;
- время восстановления;
- доступность самостоятельной выгрузки.
Например:
ежедневные копии
хранение 7 дней
Это не означает возможность восстановить версию месячной давности.
Кроме того, провайдер может не копировать:
- слишком большой аккаунт;
- отдельные временные каталоги;
- внешние базы;
- файлы сверх установленного размера;
- аккаунт при превышении допустимых ресурсов.
Условия нужно проверять отдельно.
Закончится терпение системы защиты
Высокая нагрузка не всегда создаётся реальными посетителями.
Аккаунт может получить:
- перебор паролей;
- сканирование уязвимостей;
- поисковых ботов;
- парсеры;
- спам-ботов;
- атаку на форму;
- вредоносный cron;
- заражённый PHP-скрипт.
Формально трафик безлимитный, но обработка вредоносных запросов использует CPU, процессы и базу.
Поэтому защита важна не меньше объёма ресурсов:
- ограничение входа;
- CAPTCHA;
- кэш;
- блокировка ботов;
- CDN;
- firewall;
- обновление CMS;
- удаление уязвимых плагинов;
- мониторинг файлов.
Что обычно запрещают правила допустимого использования
Конкретный список зависит от провайдера, но часто ограничиваются:
- файловые архивы, не связанные с сайтом;
- публичные файлообменники;
- торрент-сервисы;
- майнинг;
- непрерывные вычисления;
- прокси и VPN;
- сканирование сетей;
- вредоносное ПО;
- спам;
- массовые рассылки;
- фишинговые страницы;
- хранение украденных данных;
- запуск систем, требующих постоянных демонов;
- чрезмерные фоновые процессы;
- перепродажа ресурсов без подходящего тарифа.
Часть ограничений связана с законом и безопасностью, часть — с технической моделью shared-хостинга.
Что происходит при превышении
Реакция провайдера может быть разной.
Мягкое ограничение
Ресурс замедляется:
- снижается CPU;
- уменьшается скорость диска;
- новые процессы ждут;
- запросы становятся медленнее.
Сайт продолжает работать, но производительность падает.
Отказ отдельных запросов
Пользователь видит:
503 Service Unavailable
Resource limit reached
Too many processes
После освобождения ресурсов сайт восстанавливается.
Уведомление владельца
Поддержка сообщает:
- какой лимит превышен;
- когда это происходило;
- какие процессы создавали нагрузку;
- что можно оптимизировать;
- какой тариф подойдёт.
Это наиболее удобный сценарий.
Временная блокировка
Если нагрузка угрожает серверу или нарушает правила, аккаунт может быть приостановлен до исправления причины.
Перевод на другой тариф
Провайдер предлагает перейти:
- на старший shared-тариф;
- на специализированный план;
- на VPS;
- на выделенный сервер.
Важно заранее узнать, происходит ли переход автоматически и может ли появиться дополнительная оплата.
Как это устроено на Siteko. Аккаунты изолированы через CloudLinux LVE, поэтому превышение отрабатывает по «мягкому» сценарию из этого списка: при упоре в CPU сайт замедляется, при исчерпании памяти или числа процессов отдельные запросы получают ошибку 503, а после спада нагрузки всё восстанавливается само — автоматической блокировки аккаунта нет. Перейти на старший тариф можно в любой момент без переезда: сайты, базы и почта остаются на месте.
Почему скрытые лимиты хуже небольших, но понятных
Сравним два тарифа.
Тариф A
50 ГБ диска
лимиты CPU не указаны
память не указана
процессы не указаны
политика нагрузки сформулирована общими словами
Тариф B
20 ГБ диска
200% CPU
2 ГБ памяти
20 PHP-процессов
500 000 inode
20 МБ/с I/O
Тариф A выглядит более щедрым.
Но тариф B легче оценить, измерить и сопоставить с проектом.
Прозрачное ограничение полезнее маркетингового обещания без технических деталей.
Безлимит может быть нормальной моделью
Само слово «безлимитный» не означает обман.
Оно может быть удобным, если провайдер:
- подробно описывает допустимое использование;
- показывает реальные ресурсные ограничения;
- не выставляет неожиданные доплаты;
- предупреждает о превышении;
- позволяет увидеть статистику;
- предлагает понятный путь роста;
- честно отделяет хостинг сайтов от файлового хранения;
- не использует безлимит как замену технической информации.
Для большинства клиентов действительно удобнее не считать каждый гигабайт трафика или каждый почтовый ящик.
Проблема возникает не в отсутствии фиксированного числа, а в отсутствии ясных правил.
Как проверить безлимит до покупки
Найдите технические ограничения
Ищите:
CPU
RAM
PHP workers
общие процессы
inode
I/O
IOPS
размер базы
соединения с базой
тайм-ауты
cron
почтовую отправку
Если значений нет, запросите их у поддержки.
Прочитайте правила допустимого использования
Особенно разделы:
- нагрузка;
- файловое хранение;
- резервные копии;
- почта;
- фоновые процессы;
- запрещённые сервисы;
- последствия превышения.
Опишите свой сценарий конкретно
Вместо вопроса:
У вас действительно безлимит?
лучше спросить:
Сайт занимает 40 ГБ.
Из них 30 ГБ — пользовательские фотографии.
Около 600 000 файлов.
Ежемесячный трафик — 2 ТБ.
Через cron раз в час создаются миниатюры.
Подходит ли тариф и какие ограничения сработают?
Конкретное описание позволяет получить полезный ответ.
Сохраните ответ
Если важный параметр подтверждён поддержкой, сохраните переписку или ссылку на документацию.
Условия услуги могут меняться, а устное представление клиента не всегда совпадает с официальными правилами.
Вопросы поддержке
О диске
- Что означает безлимитное место?
- Разрешено ли хранить пользовательские загрузки?
- Можно ли хранить локальные резервные копии?
- Есть ли лимит одного файла?
- Есть ли лимит inode?
- Учитываются ли почта и базы?
- Какие данные считаются не связанными с сайтом?
О трафике
- Есть ли месячная квота?
- Какая скорость порта?
- Разрешена ли постоянная высокая передача?
- Можно ли размещать большие файлы?
- Какие ограничения действуют для видео и скачиваний?
- Использование CDN разрешено?
О сайтах
- Все сайты используют общие ресурсы?
- Есть ли изоляция между проектами?
- Сколько PHP-процессов доступно аккаунту?
- Можно ли создавать отдельные пользователей?
- Что происходит, если один сайт создаёт нагрузку?
О базах
- Есть ли максимальный размер одной базы?
- Сколько соединений разрешено?
- Есть ли ограничение времени запросов?
- Учитывается ли база в общем диске?
- Можно ли использовать PostgreSQL?
- Доступны ли журналы медленных запросов?
О почте
- Сколько писем можно отправлять в час?
- Можно ли делать массовые рассылки?
- Какой максимальный размер письма?
- Есть ли ограничение числа получателей?
- Входит ли почта в резервные копии?
- Учитываются ли письма в inode?
О превышениях
- Где посмотреть статистику?
- Придёт ли уведомление?
- Сайт замедлится или будет заблокирован?
- Сколько времени даётся на исправление?
- Можно ли временно увеличить ресурсы?
- Как выполняется переход на старший тариф?
Примеры, когда безлимит подходит
Корпоративные сайты
Несколько обычных сайтов занимают умеренный объём, а трафик меняется от месяца к месяцу.
Отсутствие квоты по трафику упрощает планирование.
Блог с растущей медиатекой
Количество изображений постепенно увеличивается, но все файлы связаны с работающим сайтом и не создают аномальной нагрузки.
Без фиксированной дисковой квоты владелец реже думает о переходе между тарифами.
Несколько небольших проектов
Количество сайтов меняется, но каждый использует мало ресурсов.
Безлимит по доменам удобен, если понятен общий ресурсный предел аккаунта.
Рабочая почта небольшой компании
Количество ящиков растёт постепенно, а отправка остаётся обычной деловой перепиской.
Отсутствие фиксированного числа ящиков упрощает администрирование.
Примеры, когда безлимит не решает задачу
Видеохостинг
Главная проблема — не только диск, но и:
- трафик;
- скорость порта;
- кодирование;
- постоянная нагрузка;
- хранение больших объектов.
Нужна специализированная инфраструктура.
Файловое зеркало
Даже если объём формально не ограничен, назначение может нарушать правила обычного хостинга.
Большая рассылка
Безлимитные почтовые ящики не дают права отправлять сотни тысяч писем.
Нужен сервис массовой почты.
Аналитическая база
Неограниченное количество баз не означает возможность выполнять тяжёлую аналитику на общем сервере.
Laravel Horizon
Безлимитный cron не заменяет постоянные workers и Redis.
Облачное хранилище
Хостинг сайтов не всегда разрешает хранить личные файлы, не связанные с веб-проектом.
Какой запас оставлять на безлимитном тарифе
Кажется, что при отсутствии дисковой квоты запас не нужен.
Но следует оставлять запас по другим ресурсам.
Если сайт постоянно использует:
90–100% CPU
все PHP-процессы
почти всю память
95% inode
максимум соединений с базой
он находится рядом с отказом.
Кратковременный пик, резервное копирование или атака способны превратить нормальную работу в ошибку 503.
Безлимит отменяет только необходимость считать конкретный ресурс, но не отменяет планирование нагрузки.
Грабли безлимитного хостинга
| Грабля | Что происходит | Как избежать |
|---|---|---|
| Безлимит понимают буквально | Аккаунт блокируется за сценарий вне правил | Читать допустимое использование |
| Смотрят только на диск | Сайт упирается в CPU и процессы | Проверять все ресурсы |
| Не замечают inode | Новые файлы не создаются при свободном месте | Контролировать количество объектов |
| Безлимитные сайты считают независимыми | Один проект расходует ресурсы остальных | Учитывать общий пул аккаунта |
| Неограниченные базы считают мощными | Тяжёлый SQL перегружает общий сервер | Проверять размер, соединения и запросы |
| Безлимитную почту используют для рассылок | Отправка блокируется, страдает репутация | Применять специализированный сервис |
| Хранят локальные бэкапы бесконечно | Растут диск и inode | Выносить копии во внешнее хранилище |
| Запускают постоянный cron | Накапливаются процессы | Использовать блокировки и расписание |
| Загружают личный архив | Нарушаются условия назначения услуги | Использовать объектное хранилище |
| Безлимитный трафик считают бесконечной скоростью | Скачивания упираются в порт | Проверять пропускную способность |
| Не знают последствий превышения | Сайт неожиданно блокируется | Уточнить порядок уведомления |
| Верят рекламной странице без документации | Обнаруживаются скрытые правила | Читать технические условия |
| Размещают все клиентские сайты в одном аккаунте | Взлом и нагрузка влияют на всех | Разделять окружения |
| Покупают VPS сразу после первого предупреждения | Причина нагрузки остаётся | Сначала диагностировать приложение |
Минимальный чек-лист безлимитного тарифа
Перед покупкой заполните:
Что именно заявлено безлимитным:
Допустимое назначение файлов:
Разрешены ли локальные бэкапы:
Максимальный размер файла:
Лимит inode:
CPU:
RAM:
PHP memory_limit:
PHP-процессы:
Общий лимит процессов:
I/O:
IOPS:
Размер одной базы:
Соединения с базой:
Ограничения SQL:
Минимальный интервал cron:
Максимальное время задач:
Лимит отправки почты:
Размер письма:
Ограничения рассылок:
Скорость порта:
Политика постоянного трафика:
Как показывается потребление:
Что происходит при превышении:
Когда приходит уведомление:
Как перейти на старший тариф:
Если ответы неизвестны, слово «безлимитный» пока ничего полезного не сообщает.
Что в итоге
Безлимитный хостинг не является сервером с бесконечными ресурсами.
Обычно это тариф, где один или несколько параметров не имеют простой фиксированной квоты, но регулируются:
- техническими лимитами;
- назначением услуги;
- правилами допустимого использования;
- общей нагрузкой аккаунта;
- влиянием на других клиентов.
Раньше дискового пространства могут закончиться:
- inode;
- CPU;
- память;
- PHP-процессы;
- дисковые операции;
- соединения с базой;
- время выполнения;
- лимиты cron;
- почтовая отправка;
- скорость сети.
Главное правило:
Не спрашивайте, действительно ли хостинг безлимитный. Спрашивайте, какие конкретные ограничения заменяют фиксированную квоту.
Хороший безлимитный тариф не скрывает границы. Он избавляет клиента от постоянного подсчёта мелких ресурсов, но при этом честно описывает технические возможности и допустимые сценарии.
После выбора тарифа начинается практическая работа: нужно подключить домен.
И здесь возникает другая разновидность «магии». В панели домен уже добавлен, файлы загружены, но браузер продолжает показывать старый сайт, страницу регистратора или ошибку.
В следующей части разберём DNS: записи A, AAAA, CNAME, NS, TTL, кэш и пошаговую диагностику ситуации, когда домен подключён, а сайт не открывается.
- 1 Как выбрать хостинг для сайта и не купить себе вторую работу
- 2 Виртуальный хостинг, VPS или облако: что действительно нужно вашему сайту
- 3 Гигабайты ничего не решают: как читать характеристики тарифа хостинга
- 4 «Безлимитный» хостинг: что заканчивается раньше дискового пространства вы здесь
- 5 Домен подключён, а сайт не открывается: DNS без мистики скоро
- 6 HTTPS включён, а браузер всё равно ругается: SSL без паники скоро
- 7 Письма с сайта пропадают: SMTP, SPF, DKIM и DMARC на пальцах скоро
- 8 Современный PHP-хостинг: зачем Laravel и Symfony нужны SSH, Composer, Node.js, cron и отдельная public-директория скоро
- 9 Деплой без FTP на виртуальном хостинге: Git, Composer и безопасный откат скоро
- 10 Ошибка 500 после загрузки сайта: где искать причину до обращения в поддержку скоро
- 11 Сайт тормозит на хостинге: виноват тариф, код, база или внешний сервис скоро
- 12 Бэкап есть — восстановить нельзя: проверяем резервные копии до аварии скоро
- 13 Переезд на другой хостинг без потери сайта, писем и заказов скоро
- 14 Когда виртуальный хостинг стал тесен: пора на VPS или ещё можно остаться скоро
Была статья полезной: