Антипаттерн: выбирать сервер по цене за гигабайт диска

MAATRIX

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

В чём суть антипаттерна

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

Антипаттерн проявляется так: администратор или владелец бизнеса открывает сравнительную таблицу тарифов, где указаны цена и объём диска, делит одно на другое и получает «эффективность» тарифа в рублях за гигабайт. Дальше решение принимается по этой единственной цифре, а остальные строки таблицы — тип процессора, объём RAM, тип накопителя, сетевые лимиты — остаются фоном, который бегло просматривают, но не учитывают в расчёте.

Ловушка в том, что метрика формально честная — она действительно показывает, сколько вы платите за единицу объёма хранения. Но объём хранения редко является узким местом для типовой нагрузки. Дисковое место почти всегда кончается медленно и предсказуемо, а вот нехватка IOPS, процессорного времени или пропускной способности сети бьёт мгновенно и без предупреждения — сайт начинает грузиться пять секунд вместо одной, база данных упирается в очередь запросов. Сравнивая тарифы по цене за гигабайт, вы оптимизируете не тот параметр, который определит ваш реальный опыт использования сервера.

Тип диска решает больше, чем цена за гигабайт

Первая и самая грубая ошибка — уравнивать в расчёте разные типы накопителей. HDD, SATA SSD и NVMe могут стоить похоже в пересчёте на гигабайт, особенно если провайдер закладывает в тариф с HDD запас по объёму, а в тариф с NVMe — меньший объём при той же цене. На бумаге цена за гигабайт получается сопоставимой. По факту это три разных мира производительности.

• HDD — механический накопитель с вращающимися пластинами. Годится для холодного хранения архивов и бэкапов, где важен только объём и последовательное чтение/запись большими блоками. Случайный доступ — то, чем живёт большинство баз данных и веб-приложений, — для HDD это счёт на сотни операций в секунду, что для активной нагрузки крайне мало.
• SATA SSD — твердотельный накопитель, упирающийся в потолок интерфейса SATA. Кратно быстрее HDD на случайном доступе, но сам интерфейс ограничивает и линейную скорость, и число операций в секунду.
• NVMe — подключается напрямую по шине PCIe, снимая ограничение интерфейса. Даёт на порядок больше IOPS и заметно ниже задержку отклика, что критично для баз данных, кеширующих слоёв и любой нагрузки с большим числом мелких случайных операций.

Разница между этими типами накопителей — это разница на порядки в операциях в секунду и задержке отклика, а не проценты. Если хотите разобраться в деталях, чем именно отличаются интерфейсы и когда переплата за NVMe окупается, — в статье SSD против NVMe в VPS разобрано подробно, где граница целесообразности.

Практический вывод: цена за гигабайт двух тарифов с разными типами дисков — это сравнение яблок с апельсинами, даже если цифры внешне похожи. Прежде чем считать соотношение цена/объём, убедитесь, что сравниваете одинаковый тип накопителя. Если провайдер не пишет тип диска в описании тарифа явно — это тревожный звоночек, стоит спросить у поддержки напрямую, а не полагаться на маркетинговое «быстрый SSD-накопитель», под которым иногда прячется бюджетный SATA SSD, а не NVMe.

Баланс CPU и RAM к диску: быстрый диск на слабом сервере бесполезен

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

Показательный пример — база данных на MySQL или PostgreSQL. Реальная производительность запросов зависит от связки: сколько данных помещается в буферный пул в оперативной памяти (чем больше, тем реже приходится идти на диск), сколько ядер доступно для параллельной обработки запросов, и только на третьем месте — насколько быстро диск отдаёт то, что не поместилось в память. Сервер с щедрым NVMe-диском, но 1-2 ГБ RAM для базы в несколько гигабайт, будет постоянно вымывать кеш и ходить на диск за тем, что должно было остаться в памяти — и никакой NVMe не компенсирует этот архитектурный перекос.

Обратная ситуация тоже встречается: тариф с мощным процессором и большим объёмом RAM, но узким диском по IOPS — типично для бюджетных тарифов, где на одном физическом накопителе размещено много арендаторов. Здесь процессор простаивает в ожидании ответа от диска (это видно в iostat как высокий %iowait), и добавление ядер или памяти проблему не решит.

Правило простое: диск — это одна из четырёх опор конфигурации (CPU, RAM, диск, сеть), и все они должны быть сбалансированы под конкретную нагрузку. Провайдеры формируют линейку тарифов исходя из усреднённого профиля клиента, поэтому в конкретной паре тариф А/тариф Б соотношение ресурсов может отличаться заметно, даже если цена за гигабайт диска у них одинаковая.

Что ещё остаётся за кадром: сеть, лимиты IOPS, виртуализация

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

• Сетевая пропускная способность. Тариф может ограничивать канал на уровне 100 Мбит/с или 1 Гбит/с — для сайта с большим количеством медиаконтента или для сервиса раздачи файлов это может стать более узким местом, чем сам диск.
• Лимиты IOPS на виртуализации. На виртуальных серверах провайдер часто искусственно ограничивает число операций в секунду для конкретного тарифа, независимо от физических возможностей накопителя под капотом. Формально в описании тарифа это может нигде не упоминаться отдельной строкой — а по факту именно этот лимит определит, будет ли база данных тормозить под нагрузкой.
• Тип виртуализации. Полноценная виртуализация (KVM) даёт более предсказуемую и изолированную производительность диска, чем контейнерная виртуализация, где ресурсы диска делятся между соседями по хосту менее строго.
• Оверселлинг хоста. Одинаковая заявленная скорость диска на бумаге может отличаться в разы в реальности — в зависимости от того, сколько ещё клиентов провайдер разместил на том же физическом накопителе. Это тот параметр, который вообще никогда не попадает ни в один прайс-лист.
• Резервное копирование и снапшоты. Если тариф включает автоматические снапшоты, они тоже потребляют дисковые операции в фоне и могут заметно просаживать производительность на пике нагрузки.

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

Как правильно сравнивать тарифы: методика под свою нагрузку

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

1. Опишите профиль нагрузки. Что будет работать на сервере: статический сайт, база данных, очередь сообщений, видеомонтаж, парсинг. У каждого профиля свой узкий ресурс — у сайта обычно это CPU и сеть, у базы данных — RAM и IOPS диска, у рендер-фермы — CPU и диск для временных файлов.
2. Определите узкое место заранее. Если не уверены, какой ресурс станет дефицитным — посмотрите на похожие по профилю материалы: например, для расчёта требований конкретного приложения полезны разборы вида «сколько ресурсов нужно под задачу» — они обычно уже содержат разбивку по CPU, RAM и диску под конкретный сценарий, а не абстрактную рекомендацию.
3. Сравнивайте тарифы построчно, а не по одному отношению. Составьте таблицу: CPU (ядра и тип — выделенные или разделяемые), RAM, тип диска, объём диска, заявленный или известный лимит IOPS, канал сети. Цена за гигабайт в этой таблице — это одна из колонок, а не итоговый вывод.
4. Проверяйте тип диска и лимиты у поддержки напрямую, если это не написано явно в тарифе. Формулировка вопроса: тип накопителя (HDD/SATA SSD/NVMe), есть ли лимит IOPS для тарифа, используется ли выделенный или разделяемый процессор.
5. Считайте с запасом, а не впритык. Если задача пограничная между двумя тарифами по CPU или RAM, берите тариф выше — переплата за один шаг вверх обычно меньше, чем цена ручной миграции на больший тариф через три месяца после запуска.
6. Проверяйте диск не по паспортным цифрам, а фактическим тестом, если уже арендовали сервер и сомневаетесь в реальной скорости. Честный способ — синтетический тест fio с профилем случайного чтения/записи мелкими блоками, который ближе всего к нагрузке базы данных, а не однопоточный dd, который показывает только линейную скорость и легко вводит в заблуждение. Методика такого замера подробно разобрана в статье fio для честного замера диска.

Итоговый принцип: цена за гигабайт — это одна колонка в таблице сравнения, а не сама таблица. Решение принимается по балансу ресурсов относительно конкретной нагрузки, а не по одной цифре, вырванной из контекста.

Пример: как выглядит правильное сравнение на практике

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

По метрике «цена за гигабайт» тариф А выглядит выгоднее почти вдвое — больше диска дешевле. Но для сайта с базой данных объём в 80 ГБ на HDD, скорее всего, избыточен (реальные данные CMS среднего проекта редко занимают десятки гигабайт без учёта медиатеки), а вот случайный доступ HDD и разделяемый процессор станут узким местом при росте посещаемости — сайт будет тормозить на пике трафика, а не когда закончится место на диске.

Тариф Б проигрывает по формальной метрике «₽ за ГБ», но выигрывает там, где реально считается опыт пользователя сайта: отклик базы данных на NVMe и стабильный выделенный процессор под нагрузкой. Для этого конкретного профиля — сайт с базой данных, а не файловое хранилище — тариф Б корректный выбор, несмотря на худшую цену за гигабайт.

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

Частые вопросы