- Опубликовано: 23 июл 2026
- 22
Гигабайты ничего не решают: как читать характеристики тарифа хостинга
Часть 3 из 14 · Серия «Хостинг без магии»
Владелец интернет-магазина выбирает между двумя тарифами.
Первый предлагает:
100 ГБ диска
неограниченный трафик
50 сайтов
100 баз данных
Второй выглядит скромнее:
20 ГБ диска
10 сайтов
20 баз данных
Первый тариф кажется очевидно мощнее. На нём в пять раз больше места, можно разместить больше сайтов и создать больше баз.
После переезда магазин действительно занимает только 4 ГБ из доступных 100. Но страницы открываются медленно, импорт товаров периодически завершается ошибкой, а в часы нагрузки часть посетителей получает сообщение о временной недоступности.
Поддержка объясняет:
Сайт достиг лимита процессорного времени и количества одновременно работающих процессов.
На диске при этом свободно 96 ГБ.
Пользователь купил вместительный тариф, но сайту не требовался большой склад. Ему требовалась достаточно широкая кассовая зона, через которую одновременно проходят запросы посетителей.
Объём диска — самая понятная характеристика хостинга. Его легко измерить, показать крупной цифрой и сравнить в таблице.
Но производительность динамического сайта чаще определяют другие параметры:
- процессорное время;
- оперативная память;
- количество PHP-процессов;
- лимит одновременных запросов;
- скорость дисковых операций;
- количество файлов;
- соединения с базой данных;
- время выполнения задач;
- ограничения фоновых процессов.
Разберёмся, что означают эти характеристики и почему два тарифа с одинаковыми гигабайтами могут работать совершенно по-разному.
Хостинг — это не один ресурс
Сайт использует несколько ресурсов одновременно.
Когда посетитель открывает страницу интернет-магазина, может происходить такая цепочка:
браузер отправляет запрос
↓
веб-сервер принимает соединение
↓
запускается или занимается PHP-процесс
↓
PHP читает файлы приложения
↓
выполняются запросы к базе данных
↓
читается кэш
↓
формируется HTML
↓
веб-сервер отправляет ответ
На каждом шаге существует собственное ограничение.
Большой диск не поможет, если:
- все PHP-процессы заняты;
- один запрос потребляет слишком много памяти;
- база выполняет медленный SQL;
- закончился лимит файлов;
- дисковая подсистема не успевает обрабатывать мелкие операции;
- приложение ждёт ответа внешнего API;
- cron уже запустил несколько тяжёлых импортов.
Поэтому характеристику тарифа нельзя оценивать отдельно от остальных.
Начнём с диска: сколько места действительно нужно сайту
Дисковое пространство хранит:
- файлы сайта;
- изображения;
- видео;
- базу данных;
- почту;
- журналы;
- кэш;
- временные файлы;
- резервные копии;
- Composer-зависимости;
- Node.js-зависимости;
- старые релизы.
Пример обычного корпоративного сайта:
код и CMS 300 МБ
изображения 1,5 ГБ
база данных 250 МБ
почта 2 ГБ
логи и временные файлы 500 МБ
запас 2 ГБ
Итого — около 6,5 ГБ.
Тариф на 20 ГБ оставляет более чем достаточный запас. Переход на 100 ГБ сам по себе не ускорит ни PHP, ни базу, ни загрузку страниц.
Когда большой диск действительно важен
Большой объём нужен, если проект хранит:
- фотографии в высоком разрешении;
- пользовательские видео;
- документы;
- архивы;
- резервные копии;
- почту большого числа сотрудников;
- каталоги с десятками тысяч изображений;
- результаты генерации;
- большие журналы;
- несколько копий релизов;
- локальные бэкапы баз.
Но даже тогда следует уточнить, что именно учитывается в лимите.
У разных провайдеров в общий объём могут входить:
- сайты;
- базы;
- почта;
- резервные копии;
- временные файлы;
- логи.
А могут учитываться раздельно.
Свободное место тоже необходимо
Если сайт занимает 19,8 ГБ из доступных 20, он уже находится в опасной зоне.
Свободное пространство требуется для:
- обновления CMS;
- распаковки архива;
- временной копии базы;
- создания кэша;
- загрузки нового релиза;
- генерации изображений;
- работы почты;
- записи журналов;
- выполнения Composer;
- резервного копирования.
Некоторые операции временно требуют в два раза больше места, чем итоговый файл.
Например, перед заменой большого архива система может сначала загрузить новую копию, затем распаковать её и только потом удалить старую.
Поэтому тариф не следует заполнять полностью.
Тип накопителя: HDD, SSD и NVMe
Два тарифа с одинаковым объёмом диска могут использовать разные накопители.
HDD
Механический жёсткий диск хорошо подходит для последовательного хранения больших объёмов данных, но медленнее обрабатывает множество мелких случайных операций.
SSD
Твердотельный накопитель значительно быстрее работает с небольшими файлами и случайным доступом.
NVMe
NVMe-накопители подключаются через более быстрый интерфейс и обычно обеспечивают меньшие задержки и большее число операций в секунду.
Для современного сайта важна не только скорость чтения одного большого файла.
PHP-проект может содержать десятки тысяч мелких файлов:
vendor/
storage/framework/
var/cache/
wp-content/plugins/
База данных также выполняет множество небольших операций.
Поэтому SSD или NVMe обычно предпочтительнее HDD. Однако одна надпись «NVMe» ещё не гарантирует высокую скорость тарифа: провайдер может отдельно ограничивать дисковый ввод-вывод.
Скорость диска и IOPS — разные характеристики
Дисковую производительность часто описывают двумя показателями.
Пропускная способность
Измеряется, например, в мегабайтах в секунду:
20 МБ/с
100 МБ/с
500 МБ/с
Она показывает, сколько данных можно последовательно прочитать или записать за единицу времени.
Это важно при:
- копировании архива;
- выгрузке большой базы;
- резервном копировании;
- обработке видео;
- передаче крупных файлов.
IOPS
IOPS — количество операций ввода-вывода в секунду.
Этот показатель важен при работе с большим количеством мелких файлов и случайными обращениями:
- PHP-зависимостями;
- кэшем;
- сессиями;
- базой данных;
- почтой;
- большим числом небольших изображений;
- файловым хранилищем CMS.
Представим два задания.
Первое читает один файл размером 500 МБ.
Второе читает 50 000 файлов по 10 КБ.
Общий объём почти одинаковый, но второе задание создаёт намного больше отдельных операций. Для него особенно важны задержка и IOPS.
Почему сайт может тормозить при свободном диске
Если тариф ограничивает дисковые операции, симптомы могут быть такими:
- административная панель открывается медленно;
- Composer долго устанавливает зависимости;
- WordPress медленно перебирает плагины;
- очистка кэша занимает много времени;
- база периодически ждёт диск;
- распаковка архива идёт очень медленно;
- резервное копирование влияет на сайт.
В таблицах тарифов IOPS и скорость I/O указываются не всегда. Если проект зависит от активной работы с файлами, эти параметры стоит запросить у поддержки.
Inode: почему свободные гигабайты могут не помочь
Inode — это учётная запись объекта файловой системы.
Упрощённо, один inode требуется для каждого:
- файла;
- каталога;
- символической ссылки.
Тариф может иметь:
20 ГБ диска
300 000 inode
Если сайт создал 300 000 файлов, новые файлы перестанут появляться, даже если занято только 8 ГБ.
Что расходует inode
Особенно много файлов создают:
node_modules;vendor;- кэш CMS;
- файловые сессии;
- миниатюры изображений;
- почта;
- старые резервные копии;
- временные каталоги;
- логи по отдельным датам;
- несколько копий проекта;
- каталоги релизного деплоя;
- заражённый сайт, создающий множество файлов.
Пример:
основной сайт 45 000 файлов
vendor 25 000 файлов
node_modules 120 000 файлов
почта 70 000 файлов
старые резервные копии 30 000 файлов
Итого — 290 000 объектов.
На диске может быть занято всего несколько гигабайт, но лимит inode почти исчерпан.
Симптомы исчерпания inode
- невозможно загрузить новый файл;
- не создаётся кэш;
- не сохраняется сессия;
- почта перестаёт приниматься;
- обновление CMS завершается ошибкой;
- приложение не может создать лог;
- Composer падает во время установки;
- распаковка архива останавливается.
Проверить количество файлов через SSH можно приблизительно:
find ~ -xdev | wc -l
Команда может выполняться долго на большом аккаунте.
Для отдельных каталогов:
find ~/www -xdev | wc -l
find ~/mail -xdev | wc -l
Точный расход inode удобнее смотреть в панели хостинга, если она показывает статистику.
Процессор: не только количество ядер
Процессор выполняет код:
- PHP;
- базы данных;
- архивации;
- Composer;
- cron;
- обработки изображений;
- антивирусной проверки;
- frontend-сборки;
- фоновых заданий.
В описании VPS можно увидеть:
2 vCPU
4 vCPU
8 vCPU
На виртуальном хостинге:
100% CPU
200% CPU
процессорное время
доля ядра
Эти цифры нельзя напрямую сравнивать без пояснений провайдера.
Что означает vCPU
vCPU — виртуальный процессор.
Обычно он соответствует потоку выполнения, который гипервизор предоставляет виртуальной машине.
Но два vCPU у разных провайдеров могут отличаться:
- поколением физического процессора;
- частотой;
- нагрузкой соседних VPS;
- правилами длительной загрузки;
- наличием гарантированной доли;
- режимом burst;
- лимитами виртуализации.
Поэтому фраза «4 vCPU» не говорит о производительности так же точно, как название и тест конкретного физического процессора.
Выделенное и разделяемое CPU
Некоторые тарифы предоставляют разделяемые вычислительные ресурсы. Сервер может кратковременно использовать процессор, пока физический узел не перегружен.
Другие предлагают выделенные ядра или гарантированную долю.
Для обычного сайта кратковременные всплески часто удобнее постоянной полной загрузки.
Для непрерывных вычислений, кодирования видео или тяжёлых фоновых задач важнее гарантированная производительность.
CPU на виртуальном хостинге
На виртуальном хостинге может ограничиваться:
- процент одного ядра;
- суммарная доля нескольких ядер;
- процессорное время за период;
- длительность высокой нагрузки;
- число одновременно работающих процессов.
Например, условные 100% CPU могут означать возможность полностью использовать одно ядро.
200% — два ядра или эквивалентную суммарную долю.
Но конкретная трактовка зависит от системы ограничений провайдера.
Процессорное время и календарное время
Представим, что PHP-скрипт выполнялся пять секунд.
Это не обязательно означает, что он использовал пять секунд процессора. Часть времени он мог:
- ждать базу;
- ждать диск;
- ждать внешний API;
- ждать блокировку;
- передавать данные.
Процессорное время учитывает именно периоды выполнения инструкций на CPU.
Поэтому медленная страница не всегда упирается в процессор.
Она может ждать другой ресурс.
Чем проявляется нехватка CPU
Возможные симптомы:
- страницы медленно формируются;
- административная панель зависает;
- импорт занимает слишком долго;
- генерация изображений завершается ошибкой;
- cron не успевает закончиться до следующего запуска;
- сайт замедляется во время резервного копирования;
- при высокой посещаемости растёт очередь запросов;
- аккаунт временно ограничивается.
Но высокая загрузка процессора — это симптом, а не окончательный диагноз.
Причиной может быть:
- тяжёлый плагин;
- бесконечный цикл;
- неоптимальный SQL;
- генерация отчёта;
- атака ботов;
- слишком частый cron;
- отсутствие кэша;
- заражение сайта.
Переход на более дорогой тариф увеличит запас, но не обязательно устранит причину.
Оперативная память: несколько разных лимитов
Слово «память» в тарифе может обозначать разные вещи.
Важно различать:
- общий объём памяти аккаунта или VPS;
- лимит одного PHP-процесса;
- память базы данных;
- память фоновых задач;
- память Composer и Node.js;
- файловый кэш операционной системы.
Общая память аккаунта
На виртуальном хостинге аккаунту может быть доступно, например:
1 ГБ RAM
2 ГБ RAM
4 ГБ RAM
Эту память одновременно используют:
- PHP-процессы;
- cron;
- Composer;
- Node.js;
- служебные процессы аккаунта;
- фоновые задачи.
Если одновременно работают десять PHP-процессов, каждый потребляет часть общего лимита.
memory_limit PHP
PHP имеет собственную настройку:
memory_limit = 256M
Она ограничивает память одного PHP-скрипта.
Это не означает, что весь аккаунт получил 256 МБ.
И не означает, что десять параллельных скриптов вместе ограничены теми же 256 МБ.
Теоретически десять процессов с лимитом 256 МБ могут запросить:
10 × 256 МБ = 2560 МБ
На практике не каждый процесс использует максимум, но общий лимит аккаунта всё равно должен учитывать параллельность и накладные расходы.
Почему высокий memory_limit не всегда лучше
Если установить:
memory_limit = 2048M
это не добавит физическую память тарифу.
Один ошибочный скрипт сможет занять больше общего лимита и вытеснить остальные процессы.
Разумный memory_limit должен:
- позволять выполнять нормальные задачи;
- останавливать аномальное потребление;
- соответствовать общему объёму памяти;
- учитывать число параллельных процессов.
Память VPS
На VPS указанный объём RAM используют:
- операционная система;
- веб-сервер;
- PHP-FPM;
- база данных;
- Redis;
- почта;
- мониторинг;
- системный кэш;
- все приложения.
Из условных 2 ГБ нельзя отдать все 2 ГБ PHP.
Часть уже потребуется самой системе.
Пример приблизительного распределения:
операционная система 300 МБ
веб-сервер 100 МБ
база данных 500 МБ
PHP-процессы 800 МБ
служебные процессы 150 МБ
свободный запас 150 МБ
Реальные значения зависят от нагрузки и конфигурации.
На виртуальном хостинге базу, веб-сервер и системную среду обслуживает провайдер. Поэтому один гигабайт лимита аккаунта и один гигабайт RAM маленького VPS нельзя напрямую считать равными.
Что происходит при нехватке памяти
Симптомы могут различаться.
PHP может показать:
Allowed memory size exhausted
Composer:
PHP Fatal error: Allowed memory size...
Node.js:
JavaScript heap out of memory
Процесс может быть завершён системой без красивого сообщения.
На VPS при критическом дефиците памяти ядро системы может начать завершать процессы. Иногда первым погибает PHP, база или другой крупный потребитель.
Swap не заменяет RAM
Swap использует диск как временное продолжение памяти.
Он может помочь пережить короткий всплеск, но работает значительно медленнее оперативной памяти.
Если сервер постоянно использует swap, сайт обычно начинает тормозить. Для базы данных активный swap особенно нежелателен.
PHP-процессы: сколько посетителей обслуживается одновременно
Один PHP-процесс обычно обрабатывает один запрос в конкретный момент времени.
Если тариф разрешает пять одновременно работающих PHP-процессов, упрощённая картина выглядит так:
запрос 1 → PHP-процесс 1
запрос 2 → PHP-процесс 2
запрос 3 → PHP-процесс 3
запрос 4 → PHP-процесс 4
запрос 5 → PHP-процесс 5
запрос 6 → ждёт освобождения процесса
Это не означает, что сайт способен обслуживать только пять посетителей.
Большую часть времени посетитель:
- читает страницу;
- смотрит изображение;
- вводит данные;
- загружает статические ресурсы.
PHP нужен лишь на время формирования динамического ответа.
Если страница создаётся за 0,1 секунды, один процесс может последовательно обработать много запросов.
Если каждый запрос выполняется пять секунд, очередь возникнет намного быстрее.
Почему скорость одного запроса влияет на пропускную способность
Представим тариф с десятью PHP-процессами.
Быстрый сайт
Один запрос обрабатывается за 0,1 секунды.
Упрощённо десять процессов способны завершить около ста таких запросов в секунду:
10 процессов ÷ 0,1 секунды = 100 запросов в секунду
Это грубая оценка без учёта других ресурсов, но принцип понятен.
Медленный сайт
Один запрос занимает пять секунд.
Те же десять процессов завершают примерно два запроса в секунду:
10 процессов ÷ 5 секунд = 2 запроса в секунду
Один медленный внешний API или SQL-запрос способен занять все процессы, даже почти не используя CPU.
Поэтому увеличение числа workers помогает только до определённого момента. Если каждый запрос остаётся медленным, процессы просто начинают одновременно ждать.
Какие названия встречаются в тарифах
Ограничение параллельности может называться:
- PHP workers;
- процессы PHP;
- одновременные процессы;
- entry processes;
- PHP-FPM children;
- динамические запросы;
- параллельные обработчики;
- лимит процессов аккаунта.
Термины зависят от панели и системы изоляции.
Перед сравнением нужно уточнить, что именно считает провайдер.
Например, общий лимит процессов может включать:
- PHP;
- SSH;
- cron;
- Composer;
- фоновые команды.
А лимит PHP workers — только обработчики веб-запросов.
Что происходит при исчерпании процессов
В зависимости от конфигурации:
- запрос ждёт в очереди;
- страница открывается медленнее;
- веб-сервер возвращает 503;
- процесс не запускается;
- панель фиксирует превышение лимита;
- часть фоновых задач откладывается.
Кратковременное достижение лимита во время пика не обязательно означает проблему.
Если лимит достигается постоянно, нужно выяснить:
- сколько длится запрос;
- какие URL занимают процессы;
- нет ли медленного API;
- не запущены ли параллельно несколько cron-задач;
- работает ли кэш;
- нет ли атаки или ботов;
- хватает ли тарифа.
Одновременные соединения — не то же самое, что PHP-процессы
Браузер может одновременно загружать:
- HTML;
- CSS;
- JavaScript;
- изображения;
- шрифты;
- API-ответы.
Статические файлы обычно обслуживает веб-сервер без PHP.
Поэтому сайт способен иметь много одновременных соединений при небольшом количестве PHP-процессов.
Следует различать:
- сетевые соединения;
- динамические запросы;
- PHP-процессы;
- соединения с базой;
- фоновые процессы.
Один посетитель тоже может создать несколько динамических запросов одновременно, например при работе сложной административной панели.
Время выполнения PHP
На тарифе может существовать ограничение:
max_execution_time = 60
Оно определяет, сколько времени PHP-скрипт может выполняться в веб-запросе.
Это защищает сервер от зависших программ, но влияет на:
- импорт;
- экспорт;
- генерацию отчётов;
- обработку больших изображений;
- обновление CMS;
- длительные интеграции;
- резервное копирование через PHP.
Тяжёлые задачи лучше:
- делить на части;
- переносить в очередь;
- запускать из CLI;
- выполнять по cron;
- обрабатывать пакетами;
- выносить в специализированный сервис.
Просто увеличение времени до нескольких часов может занять PHP-процесс и создать очередь для посетителей.
CLI и веб-запрос могут иметь разные лимиты
Команда:
php import.php
может работать в другом режиме, чем запрос через браузер.
Могут отличаться:
memory_limit;- время выполнения;
- версия PHP;
- доступные расширения;
- переменные окружения;
- пользователь процесса;
- рабочий каталог.
Для проектов с Composer, cron и консольными задачами важно проверить ограничения не только веб-сайта, но и CLI.
База данных: количество баз почти ничего не говорит о скорости
Тариф может разрешать:
50 баз данных
100 баз данных
неограниченное количество баз
Это показывает, сколько отдельных баз можно создать.
Но не говорит:
- сколько запросов они способны выполнять;
- сколько соединений разрешено;
- какой объём данных допустим;
- насколько быстрый диск;
- какая версия СУБД;
- сколько памяти выделено серверу базы;
- ограничено ли время запросов;
- насколько база загружена соседними проектами.
Одна хорошо спроектированная база может обслуживать крупный сайт.
Сто пустых баз не создают производительности.
Соединения с базой
Каждый PHP-процесс может открыть одно или несколько соединений.
Если одновременно работают двадцать PHP-процессов, приложение теоретически способно создать двадцать и более подключений.
Лимит может существовать:
- на пользователя базы;
- на аккаунт;
- на одну базу;
- на весь сервер;
- на единицу времени.
При его превышении появляются ошибки вроде:
Too many connections
или:
User has more than max_user_connections active connections
Причины могут быть разными:
- слишком много параллельных PHP-процессов;
- соединения не освобождаются;
- тяжёлые запросы выполняются долго;
- база перегружена;
- приложение открывает несколько подключений на запрос;
- фоновые workers постоянно держат соединения.
Размер базы данных
Ограничение может задаваться отдельно от файлового диска.
Например:
диск сайтов — 20 ГБ
максимальный размер одной базы — 2 ГБ
Или все базы могут учитываться в общем объёме аккаунта.
Перед переносом следует измерить не только размер SQL-дампа.
Сжатый архив:
database.sql.gz — 400 МБ
после распаковки и импорта может превратиться в базу на несколько гигабайт.
Дополнительное место потребуется для:
- индексов;
- временных таблиц;
- операций
ALTER TABLE; - резервных копий;
- журналов транзакций.
Медленный запрос не лечится дополнительными гигабайтами
Запрос без индекса может перебирать миллионы строк.
Он будет:
- нагружать CPU базы;
- читать диск;
- удерживать соединение;
- занимать PHP-процесс;
- замедлять другие запросы.
Переезд на более мощный тариф может временно улучшить ситуацию, но с ростом таблицы проблема вернётся.
Производительность базы зависит от:
- индексов;
- структуры запросов;
- количества выбранных данных;
- блокировок;
- типов полей;
- схемы отношений;
- кэширования;
- размера рабочих наборов;
- конфигурации СУБД.
В статье №11 мы отдельно разберём, как отличить нехватку тарифа от медленного кода и базы.
Трафик и пропускная способность сети
Трафик — объём данных, переданных посетителям и полученных от них за период.
Например:
500 ГБ в месяц
1 ТБ в месяц
неограниченный трафик
Если одна страница со всеми изображениями весит 2 МБ, то 100 000 её полных загрузок создадут приблизительно:
2 МБ × 100 000 = 200 000 МБ
То есть около 200 ГБ без учёта кэша, ботов, административной панели и остальных страниц.
Трафик не равен скорости порта
Тариф может иметь неограниченный месячный объём, но ограниченную скорость соединения.
Например:
неограниченный трафик
порт до 100 Мбит/с
И наоборот, высокая скорость порта не означает неограниченный месячный трафик.
Важно различать:
- месячный объём;
- скорость порта;
- ограничения исходящего трафика;
- региональную связность;
- защиту от атак;
- использование CDN.
Что больше всего расходует трафик
- изображения;
- видео;
- файлы для скачивания;
- резервные копии;
- обновления;
- боты;
- API;
- горячие ссылки на изображения с других сайтов;
- отсутствие кэширования.
HTML динамической страницы обычно занимает меньше, чем медиаконтент.
«Неограниченный трафик» не означает бесконечную нагрузку
Провайдер может не считать гигабайты, но продолжать ограничивать:
- CPU;
- память;
- процессы;
- скорость порта;
- число соединений;
- допустимое использование;
- продолжительную нагрузку.
Сайт способен уложиться в неограниченный трафик и одновременно превысить CPU через несколько минут после запуска тяжёлого скрипта.
Разбору слова «безлимитный» будет посвящена следующая статья серии.
Количество сайтов и доменов
Тариф может позволять разместить:
1 сайт
10 сайтов
неограниченное количество сайтов
Это ограничение организации аккаунта, а не его производительности.
Десять сайтов используют общий набор ресурсов тарифа:
- CPU;
- память;
- PHP-процессы;
- диск;
- inode;
- трафик;
- базы;
- почту.
Если один проект создаёт нагрузку, остальные могут тоже почувствовать нехватку ресурсов.
«Неограниченные сайты» не дают неограниченный сервер
Можно разместить сто небольших лендингов.
Но сто интернет-магазинов не станут работать только потому, что панель разрешает создать сто доменов.
Количество сайтов говорит о лицензии и структуре тарифа. Мощность нужно смотреть отдельно.
Почта тоже расходует ресурсы
Почтовые ящики занимают:
- диск;
- inode;
- трафик;
- лимиты отправки;
- число сообщений;
- место резервных копий.
Один ящик с 30 ГБ вложений может занять больше места, чем все сайты аккаунта.
Большое число мелких писем способно исчерпать inode раньше диска.
Следует проверить:
- входит ли почта в общий объём;
- максимальный размер ящика;
- максимальный размер письма;
- количество отправлений в час;
- ограничения массовой рассылки;
- срок хранения спама и корзины;
- наличие резервного копирования почты.
Cron и фоновые задачи
Наличие cron в таблице тарифа недостаточно.
Важно уточнить:
- минимальный интервал;
- максимальное время выполнения;
- число одновременных задач;
- общий лимит процессов;
- доступную версию PHP;
- память;
- возможность блокировки повторного запуска;
- сохранение вывода и ошибок.
Рассмотрим задание импорта, запускаемое каждую минуту.
Если один запуск занимает три минуты, через некоторое время одновременно могут работать три копии:
10:00 — запуск 1
10:01 — запуск 2
10:02 — запуск 3
10:03 — запуск 4
Каждая копия использует память, CPU и соединение с базой.
Для защиты применяют блокировку:
flock -n /tmp/import.lock php artisan import
или собственный механизм приложения.
Минимальный интервал cron важен для планировщиков Laravel и других систем, но частый запуск не должен превращаться в бесконтрольную параллельность.
Резервные копии и ресурсы
Фраза «резервные копии включены» не является характеристикой производительности, но сильно влияет на реальную ценность тарифа.
Следует выяснить:
- что копируется;
- как часто;
- сколько хранится;
- где находятся копии;
- входят ли они в дисковую квоту;
- можно ли скачать архив;
- можно ли восстановить отдельный файл;
- можно ли восстановить одну базу;
- создаётся ли копия при переполненном аккаунте;
- проверяет ли кто-то успешность резервирования.
Локальная копия внутри того же аккаунта:
/home/user/backups/site.zip
расходует диск и inode. Она полезна для быстрого отката, но не защищает от потери всего аккаунта.
Лимит файловых дескрипторов и открытых файлов
В некоторых средах ограничивается количество одновременно открытых файлов и соединений.
Обычный сайт редко сталкивается с этим напрямую, но проблема возможна при:
- большом числе процессов;
- постоянных соединениях;
- утечке файловых дескрипторов;
- обработке множества файлов;
- нестандартных службах;
- большом количестве логов.
На стандартном виртуальном хостинге такие системные лимиты обычно настраивает провайдер.
На VPS ответственность за них может лежать на администраторе.
Что такое overselling
Провайдеры не всегда выделяют каждому клиенту физические ресурсы, которые постоянно простаивают в ожидании нагрузки.
Хостинг строится на предположении, что сайты используют CPU, память и сеть не одновременно и не непрерывно.
Это похоже на электросеть: мощность рассчитана на статистическое потребление, а не на одновременное включение всех приборов во всех квартирах.
Сам по себе overselling не означает плохую услугу.
Проблема возникает, если провайдер:
- размещает слишком много клиентов;
- не контролирует перегрузку;
- не ограничивает нарушителей;
- использует медленные диски;
- не добавляет мощности;
- скрывает постоянную нехватку ресурсов.
Качество зависит от управления инфраструктурой, а не только от самого факта совместного использования.
Почему одинаковые тарифы работают по-разному
Рассмотрим два предложения:
2 CPU
2 ГБ RAM
20 ГБ NVMe
Они могут различаться по:
- поколению процессора;
- частоте;
- допустимой длительной нагрузке;
- числу соседей;
- IOPS;
- задержкам диска;
- скорости базы;
- конфигурации PHP;
- OPcache;
- версии СУБД;
- качеству сети;
- резервированию;
- мониторингу;
- лимитам процессов;
- политике поддержки.
Таблица характеристик не показывает весь результат.
Поэтому полезны:
- тестовый период;
- перенос копии сайта;
- измерение времени ответа;
- проверка панели;
- запуск Composer;
- тест импорта;
- чтение технической документации;
- вопросы поддержке.
Но синтетический тест одного файла тоже не отражает работу реального проекта.
Почему тест phpinfo() ничего не говорит о скорости
Страница phpinfo() показывает:
- версию PHP;
- расширения;
- настройки;
- переменные;
- пути.
Она полезна для проверки совместимости, но не измеряет:
- скорость базы;
- число процессов;
- IOPS;
- реальную нагрузку;
- производительность приложения;
- качество кэша.
Так же мало говорит простой скрипт:
<?php
echo microtime(true);
Для сравнения лучше запускать реальный проект или его копию.
Какие показатели измерять на работающем сайте
TTFB
Time to First Byte — время до получения первого байта ответа.
Оно включает:
- сеть;
- обработку веб-сервером;
- работу PHP;
- запросы к базе;
- ожидание внешних сервисов.
Высокий TTFB может указывать на медленную серверную часть, но сам по себе не показывает конкретную причину.
Время выполнения приложения
Фреймворк или профилировщик может показать:
- общее время;
- время SQL;
- число запросов;
- память;
- внешние HTTP-запросы;
- работу шаблонов.
Нагрузка ресурсов
Панель хостинга может показывать:
- CPU;
- RAM;
- число процессов;
- I/O;
- превышения;
- inode;
- трафик.
Полезно сопоставлять время проблемы с графиками.
Например:
сайт тормозил с 14:00 до 14:15
CPU был 20%
PHP-процессы — 100%
Это указывает не на нехватку CPU, а на занятые процессы. Они могли ждать базу или внешний API.
Одна цифра редко даёт диагноз
Рассмотрим несколько сочетаний.
CPU 100%, процессы 100%
Вероятно, запросы активно вычисляют.
Проверяем:
- тяжёлый PHP-код;
- отсутствие кэша;
- ботов;
- генерацию;
- cron;
- заражение.
CPU 20%, процессы 100%
Процессы, скорее всего, ждут:
- базу;
- диск;
- внешний API;
- блокировку;
- медленный сетевой ресурс.
Память 100%, CPU невысокий
Возможны:
- слишком много параллельных процессов;
- тяжёлые объекты;
- утечка памяти;
- крупный импорт;
- Node.js-сборка;
- Composer.
I/O 100%, CPU невысокий
Проверяем:
- резервное копирование;
- архивирование;
- большое число мелких файлов;
- базу;
- логи;
- заражение;
- массовую генерацию изображений.
Inode 100%, диск 40%
Нужно удалять или переносить ненужные файлы, а не покупать только дополнительные гигабайты.
Как оценить необходимое число PHP-процессов
Точного универсального числа нет.
Оно зависит от:
- скорости каждого запроса;
- посещаемости;
- доли динамических страниц;
- кэширования;
- фоновых запросов;
- административной активности;
- внешних интеграций;
- поведения ботов.
Для небольшого сайта несколько процессов могут быть достаточны, если страницы формируются быстро.
Для магазина с медленными API и административными импортами даже десятков может не хватить.
Правильная последовательность:
- измерить длительность запросов;
- убрать очевидные задержки;
- включить кэш там, где возможно;
- посмотреть пики параллельности;
- только затем увеличивать число workers.
Удвоение процессов при неизменной памяти может привести к тому, что каждый процесс получит меньше доступного запаса.
Как оценить память
Предположим:
среднее потребление одного PHP-процесса — 80 МБ
максимальное число процессов — 10
Только PHP может потребовать около:
80 МБ × 10 = 800 МБ
Дополнительно нужны:
- CLI-задачи;
- Composer;
- служебные процессы;
- запас на пики.
Но среднее значение не равно максимальному.
Импорт или обработка изображения может использовать 300 МБ, тогда как обычная страница — 50 МБ.
Поэтому нужно учитывать реальные сценарии, а не только главную страницу.
Как оценить диск и inode
Перед переносом полезно измерить:
du -sh .
Количество объектов:
find . -xdev | wc -l
Отдельно проверить:
du -sh vendor node_modules storage public/uploads 2>/dev/null
и:
find vendor -xdev | wc -l
find node_modules -xdev | wc -l
find storage -xdev | wc -l
Добавьте запас на:
- рост контента;
- почту;
- временные файлы;
- обновления;
- резервные копии;
- следующий релиз.
Не следует выбирать тариф, в который проект помещается только после удаления кэша и логов.
Как читать таблицу тарифа
Рассмотрим условное предложение:
20 ГБ NVMe
2 CPU
2 ГБ RAM
20 PHP-процессов
20 МБ/с I/O
300 000 inode
50 баз данных
неограниченный трафик
20 ГБ NVMe
Показывает объём и тип накопителя.
Не говорит о допустимых IOPS, резервировании и том, учитываются ли почта и базы.
2 CPU
Нужно уточнить:
- два полных ядра или суммарная доля;
- разделяемые или гарантированные;
- есть ли лимит длительной нагрузки.
2 ГБ RAM
Нужно понять:
- общий лимит аккаунта;
- включает ли CLI;
- как учитываются фоновые процессы;
- какой
memory_limitу одного PHP-запроса.
20 PHP-процессов
Показывает потенциальную параллельность динамических запросов.
Но реальная пропускная способность зависит от длительности каждого запроса.
20 МБ/с I/O
Это ограничение последовательной скорости.
Нужен отдельный ответ по IOPS, если проект активно работает с мелкими файлами.
300 000 inode
Это максимум файлов и каталогов.
Следует учитывать почту, кэши, зависимости и резервные копии.
50 баз данных
Показывает количество создаваемых баз, но не производительность и не лимит соединений.
Неограниченный трафик
Нужно читать правила допустимого использования и проверять скорость порта.
Вопросы, которые следует задать поддержке
Про CPU
- Что означает 100% или одна единица CPU?
- Разрешена ли постоянная нагрузка?
- Есть ли кратковременный burst?
- Что происходит при превышении?
- Можно ли увидеть график использования?
Про память
- Это общий лимит аккаунта или одного процесса?
- Какой
memory_limitу PHP? - Учитываются ли SSH, cron, Composer и Node.js?
- Что происходит при превышении?
Про процессы
- Сколько PHP workers доступно?
- Есть ли общий лимит процессов?
- Считаются ли cron и SSH-команды?
- Что происходит при занятии всех workers?
- Показывает ли панель статистику превышений?
Про диск
- Используются SSD или NVMe?
- Как ограничены I/O и IOPS?
- Учитываются ли базы и почта?
- Входят ли резервные копии в квоту?
- Что происходит при заполнении диска?
Про inode
- Какой лимит файлов?
- Учитывается ли почта?
- Можно ли увидеть расход в панели?
- Что происходит при превышении?
Про базу данных
- Какая версия MySQL или PostgreSQL?
- Какой максимальный размер базы?
- Есть ли лимит соединений?
- Ограничивается ли время запросов?
- Доступен ли slow query log?
- Учитывается ли база в общем диске?
Про сеть
- Есть ли месячный лимит трафика?
- Какая скорость порта?
- Ограничивается ли исходящий трафик?
- Есть ли защита от DDoS?
- Можно ли использовать внешний CDN?
Как сравнить два тарифа
Создайте собственную таблицу, а не ориентируйтесь только на маркетинговую.
| Параметр | Тариф A | Тариф B |
|---|---|---|
| Диск | 100 ГБ SSD | 20 ГБ NVMe |
| CPU | Не указан | 200% |
| RAM | Не указана | 2 ГБ |
| PHP-процессы | 5 | 20 |
| I/O | Не указан | 20 МБ/с |
| Inode | 200 000 | 500 000 |
| Размер базы | 1 ГБ | 5 ГБ |
| Соединения БД | Не указаны | 30 |
| Cron | Раз в 15 минут | Раз в минуту |
| SSH | Нет | Есть |
| Логи ресурсов | Нет | Есть |
| Бэкапы | Еженедельно | Ежедневно |
Тариф A всё ещё может быть подходящим для большого архива статических файлов.
Но для динамического PHP-приложения тариф B выглядит более предсказуемым, несмотря на меньший диск.
Примеры выбора по типу проекта
Сайт-визитка
Важно:
- небольшой диск;
- несколько PHP-процессов;
- SSL;
- почта;
- резервные копии;
- стабильная среда.
100 ГБ обычно не требуется.
WordPress-блог
Важно:
- PHP-процессы;
- CPU;
- быстрый диск;
- база;
- inode;
- кэширование;
- резервное копирование.
Большое число плагинов и миниатюр увеличивает расход файлов.
Интернет-магазин
Важно:
- параллельные PHP-процессы;
- память;
- база;
- cron;
- соединения;
- I/O;
- логи;
- возможность быстро повысить тариф.
Количество заказов важнее количества создаваемых баз.
Laravel или Symfony
Важно:
- PHP и расширения;
- SSH;
- Composer;
- память CLI;
- cron;
- Node.js при сборке;
- inode для
vendorиnode_modules; - Document Root;
- процессы;
- доступ к логам.
Фотоархив
Важно:
- диск;
- inode;
- трафик;
- скорость загрузки;
- обработка изображений;
- резервное копирование.
Здесь объём хранилища действительно может быть главным параметром.
API
Важно:
- CPU;
- память;
- PHP-процессы;
- база;
- сеть;
- задержки;
- стабильность под параллельной нагрузкой.
Диск может почти не использоваться.
Красные флаги в описании тарифа
Указаны только гигабайты и число сайтов
Для динамического проекта информации недостаточно.
Не описаны ресурсные лимиты
Они всё равно существуют. Лучше узнать их до покупки.
«Мощный процессор» без цифр
Непонятно, какая доля доступна аккаунту.
«Неограниченная память»
Физически бесконечной памяти нет. Возможно, ограничение реализовано через процессы или правила нагрузки.
«Неограниченные базы»
Это не характеристика скорости базы.
«NVMe» без лимитов I/O
Быстрый накопитель может быть ограничен тарифом.
Огромный диск при низком inode
Место нельзя использовать полностью для большого количества мелких файлов.
Нет статистики ресурсов
Без неё сложно понять, почему сайт замедляется.
Как это устроено на Siteko. Аккаунты на виртуальном хостинге изолированы через CloudLinux LVE: у каждого тарифа есть собственные лимиты CPU, памяти и числа процессов, поэтому сосед по серверу не заберёт ваши ресурсы. При кратковременном превышении лимита CPU сайт замедляется, а не отключается; жёсткие ошибки появляются только при исчерпании памяти или числа процессов. Конкретные лимиты тарифа по CPU, памяти, процессам и inode можно запросить у поддержки — это нормальный вопрос, и мы на него отвечаем до покупки.
Грабли при чтении характеристик хостинга
| Грабля | Что происходит | Как избежать |
|---|---|---|
| Тариф выбирают по диску | Сайт упирается в CPU или процессы | Сравнивать весь набор ресурсов |
memory_limit принимают за RAM тарифа |
Несколько PHP-процессов исчерпывают общую память | Разделять память процесса и аккаунта |
| Количество баз считают показателем мощности | Одна база работает медленно на перегруженном сервере | Проверять соединения, версию и лимиты |
| Не учитывают inode | Новые файлы не создаются при свободном диске | Считать количество объектов |
| NVMe считают гарантией скорости | Тариф ограничен по I/O или IOPS | Запросить реальные лимиты |
| Увеличивают число workers без памяти | Процессы начинают завершаться | Согласовывать параллельность и RAM |
| Увеличивают память вместо исправления кода | Ошибка повторяется на новом лимите | Найти причину потребления |
| Cron запускается чаще, чем завершается | Копии задачи накапливаются | Использовать блокировку |
| Сравнивают vCPU как одинаковые единицы | Производительность оказывается разной | Учитывать тип CPU и правила нагрузки |
| Не учитывают почту | Заканчиваются диск и inode | Считать весь аккаунт |
| Не оставляют свободное место | Обновления и бэкапы не создаются | Держать рабочий запас |
| Верят в неограниченный трафик | Сайт упирается в CPU или скорость порта | Читать остальные ограничения |
| Размещают много сайтов на одном тарифе | Один проект влияет на остальные | Учитывать общий пул ресурсов |
| Покупают тариф без графиков нагрузки | Нельзя определить узкое место | Выбирать прозрачную статистику |
Минимальный чек-лист тарифа
Перед покупкой зафиксируйте:
Диск:
Тип диска:
I/O:
IOPS:
Inode:
CPU:
Правила длительной нагрузки:
Общая RAM:
PHP memory_limit:
PHP-процессы:
Общий лимит процессов:
Максимальное время web-запроса:
Лимиты CLI:
Минимальный интервал cron:
Версия базы:
Максимальный размер базы:
Лимит соединений:
Месячный трафик:
Скорость порта:
Учитывается ли почта в диске:
Учитываются ли базы в диске:
Учитываются ли бэкапы в диске:
Есть ли графики ресурсов:
Что происходит при превышении:
Если половина параметров неизвестна, тариф пока невозможно нормально сравнить.
Как выбрать запас
Не нужно покупать десятикратный объём каждого ресурса.
Но тариф не должен постоянно работать у предела.
Разумно оставить запас для:
- роста посещаемости;
- обновлений;
- новых функций;
- фоновых задач;
- сезонных пиков;
- резервного копирования;
- временных файлов;
- неидеально оптимизированного кода.
Если обычная нагрузка постоянно использует 90–100% CPU, памяти или процессов, проект слишком близко к отказу.
Если ресурсов используется 5%, а тариф выбран «на миллион посетителей», возможно, инфраструктура избыточна.
Цель — не минимальное и не максимальное потребление, а предсказуемая работа с резервом.
Что в итоге
Объём диска — лишь одна характеристика хостинга.
Он показывает, сколько данных можно хранить, но почти ничего не говорит о том, насколько быстро динамический сайт будет обрабатывать запросы.
Производительность и устойчивость зависят от сочетания:
- CPU;
- общей памяти;
memory_limit;- PHP-процессов;
- времени запросов;
- I/O;
- IOPS;
- inode;
- базы данных;
- соединений;
- cron;
- сети.
Главное правило:
Сравнивайте не красивые цифры, а узкие места вашего проекта.
Фотоархиву действительно нужен большой диск.
Интернет-магазину важнее PHP-процессы, база и cron.
Laravel-проекту нужны CLI-память, Composer, inode и подходящее окружение.
API может почти не использовать диск, но требовать высокой параллельности.
Перед покупкой измерьте существующий проект, составьте список обязательных ресурсов и запросите параметры, которых нет в таблице.
И особенно внимательно относитесь к слову «неограниченный».
Неограниченное количество сайтов не означает неограниченное число процессов. Неограниченный трафик не означает бесконечный CPU. Неограниченный диск почти всегда сопровождается правилами допустимого использования.
В следующей статье разберём, что заканчивается на «безлимитном» хостинге раньше места: процессорное время, inode, почта, база, фоновые задачи и терпение технической поддержки.
Была статья полезной:
