К содержанию
Siberian V

Сколько ядер, памяти и диска нужно VPS под вашу задачу

Как выбрать VPS по задаче: что нагружает процессор, память и диск у сайта, Docker, хранилища файлов и сборок

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

Один сервер, три разных ресурса

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

Поэтому «подороже и побольше» не решение. Задача определяет, какой из ресурсов упрётся первым, и только его стоит брать с запасом. Схема ниже показывает типовые перекосы, а точные ориентиры по задачам — в таблице дальше.

Сначала измерьте, потом выбирайте

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

free -h
uptime
df -h
docker stats --no-stream

В выводе free -h смотрите на столбец available: это память, которую система может отдать новому процессу, не трогая рабочие. Столбец used вводит в заблуждение: Linux занимает свободную память под кеш файлов и отдаёт его по первому требованию, поэтому «занято 90 %» при большом available тревоги не значит.

uptime показывает среднюю нагрузку за 1, 5 и 15 минут (load average). Сравнивайте её с числом ядер из nproc: на машине с двумя ядрами значение около 2 означает, что процессор занят полностью, а стабильно выше — что задачи стоят в очереди. docker stats разбивает память и процессор по контейнерам и сразу показывает, какой сервис съедает больше всех.

Один замер ничего не доказывает. Снимите показания утром, в час пик и в день, когда обычно запускается тяжёлая работа: резервное копирование, рассылка, сборка. Именно пик задаёт нужную конфигурацию, а не среднее значение.

Ориентиры по типовым задачам

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

ЗадачаЯдраПамятьДискЧто упрётся первым
Сайт-визитка, статика1512 МБ — 1 ГБ10–20 ГБНичего: ресурсов обычно хватает с запасом
Сайт с базой данных (WordPress и подобные)1–22 ГБ20–40 ГБПамять, затем скорость диска
Бот или небольшой парсер1512 МБ — 1 ГБ10–20 ГБСеть и стабильность, не ресурсы
Несколько сервисов в Docker24 ГБ40–60 ГБПамять и место под образы
Файловое облако, хранилище копий1–22 ГБПо объёму данных плюс запасДиск
Сборка проектов, тесты4 и больше4–8 ГБ40 ГБ и большеЯдра на время сборки
Личный туннельный сервер для домашних устройств1512 МБ — 1 ГБ10 ГБКанал и расположение, не ресурсы

Строки для туннельного сервера и для бота часто удивляют: им нужно меньше всего. Такие сервисы почти не считают, а перекладывают пакеты и данные, поэтому важнее сеть, чем мощность. Как проверять канал и расположение, описано в статье про пинг до Германии, а про сам выбор площадки — в разборе семи параметров VPS.

Процессор: больше ядер не значит быстрее

Ядра помогают, когда есть что делать параллельно: несколько посетителей одновременно, несколько контейнеров, сборка с несколькими потоками. Один запрос к PHP-странице или одна транзакция в базе работают в одном потоке, и второе ядро их не ускорит. Если сайт открывается медленно при единственном посетителе, причина в коде, запросах к базе или медленном диске, а не в количестве ядер.

Признак нехватки процессора — load average выше числа ядер на протяжении долгого времени и высокое значение us и sy в top. Если же нагрузка высокая, а процессор простаивает, ждёт, скорее всего, диск: смотрите поле wa в строке %Cpu(s). Отдельный случай — столбец st, в котором виден процессор, забранный соседями по хосту; он разобран в статье о выборе VPS, и решается он сменой площадки, а не добавлением ядер.

Память: считайте по процессам, а не по ощущениям

Оценка памяти складывается из слагаемых. Система без сервисов занимает немного. К ней добавьте то, что запущено постоянно: веб-сервер, интерпретатор языка, базу, каждый контейнер. Сумму увеличьте на 20–30 % запаса: пик всегда выше среднего, а ядру нужна свободная память под кеш файлов.

База данных — главный потребитель, и её аппетит настраивается. В документации PostgreSQL для выделенного сервера баз данных начальным значением shared_buffers названа четверть оперативной памяти, а в MySQL буфер InnoDB (innodb_buffer_pool_size) на выделенном сервере делают намного больше. Если база делит машину с сайтом и другими сервисами, этот объём надо уменьшить, иначе сервисы отнимут друг у друга память, и сработает защита ядра.

Нехватку памяти показывает система:

dmesg -T | grep -i "out of memory"
vmstat 1 10

Строка «Out of memory: Killed process» значит, что ядро уже завершило процесс, чтобы спасти остальные. Ненулевые значения в столбцах si и so у vmstat говорят, что система активно гоняет страницы в swap и обратно, и это замедляет работу сильнее, чем кажется. Небольшой swap-файл стоит держать на любом сервере: он страхует от случайного пика. Но постоянная работа на swap — признак того, что нужно больше оперативной памяти.

Диск: где место исчезает

Объём диска складывается из системы, самих данных, роста за ближайшие месяцы и служебного мусора. Мусора набирается больше, чем ожидаешь:

Найти крупные каталоги помогает du -h --max-depth=1 / | sort -h. На файловой системе ext4 по умолчанию часть блоков (обычно 5 %) зарезервирована для root, поэтому обычный пользователь упирается в потолок раньше, чем df покажет полное заполнение.

Заполненный диск — единственный случай, когда сервис падает без предупреждения, поэтому настройте оповещение хотя бы на 80 %. Расширять диск проще, чем сжимать: многие провайдеры не позволяют уменьшить его после увеличения. Берите с запасом на полгода, не больше. Про скорость диска и лимит операций читайте в статье о выборе VPS, объём и скорость — разные параметры.

Пример: как из замеров получается конфигурация

Допустим, на домашней машине работают три контейнера: сайт на WordPress, база к нему и небольшая панель мониторинга. docker stats в обычное время показывает около 300 МБ на сайт, 400 МБ на базу и 150 МБ на панель, итого 850 МБ. Система добавляет ещё 200–300 МБ. Получается около 1,1 ГБ, с запасом в 30 % — чуть меньше 1,5 ГБ. Ближайшая стандартная конфигурация — 2 ГБ, и она подходит с небольшим запасом на рост.

Нагрузка по uptime держится около 0,3 на двух ядрах, значит, процессора хватает, а одного ядра для начала достаточно. Данные занимают 6 ГБ, система с образами — 8 ГБ: с запасом на полгода хватит 30 ГБ. Итог: 1 ядро, 2 ГБ памяти, 30 ГБ диска. Цифры вымышленные, но порядок рассуждения от этого не меняется: от замеров к сумме, от суммы к ближайшей конфигурации.

Когда пора увеличивать конфигурацию

Не ждите жалоб от пользователей. Три признака говорят, что пора:

  1. available в free -h в пик падает ниже 10–15 % от общего объёма, или в dmesg появляются записи об убитых процессах;
  2. load average долго держится выше числа ядер, и это не одна разовая задача;
  3. на диске занято больше 70–80 %, а данные продолжают прирастать.

Порядок обычно такой: сначала память, потом ядра, потом диск. Перед повышением посмотрите, нет ли дешёвого выхода: лишний контейнер, который можно остановить, раздувшийся журнал или кеш, который стоит ограничить. Для первой проверки нового сервера пригодится список из настройки VPS на Ubuntu.

Если свой сервер нужен только для личных устройств

Часто сервер берут ради одного: чтобы телефон и ноутбук выходили в сеть через зарубежный адрес, а российские сайты открывались напрямую. Для такой задачи ресурсов нужно мало, зато нужны время на настройку и дежурство над сервером. Если администрировать машину не хочется, в Siberian V для этого есть подключение через приложение Karing: российские сайты идут напрямую, остальное — через зарубежный сервер. Чем свой сервер отличается от готовой подписки, разобрано в статье про сервер для роутера.

Подключить

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

Хватит ли VPS с 1 ГБ памяти для сайта на WordPress?

Для небольшого сайта с кешем хватит, если на машине нет ничего лишнего: веб-сервер, PHP-FPM и база занимают большую часть гигабайта. Запаса почти не будет, поэтому добавьте swap и следите за столбцом available в free -h. Если появился плагин с тяжёлыми запросами или вырос поток посетителей, первой берут память.

Что поднимать первым: ядра, память или диск?

Сначала смотрите на память: её нехватка ломает работу сильнее всего, ядро завершает процессы, а база падает. Ядра добавляют, когда load average долго держится выше числа ядер. Диск расширяют, когда занято больше 70–80 % места. Для проверки хватает free -h, uptime и df -h.

Нужен ли swap, если памяти достаточно?

Небольшой swap полезен и в этом случае: система выгружает туда давно не нужные страницы и оставляет больше памяти под кеш файлов. Заменой оперативной памяти он не служит. Если swap постоянно растёт и в vmstat в столбцах si и so идут ненулевые значения, памяти не хватает.

Как узнать, сколько ресурсов реально использует сервер?

Снимите показания в обычное время и в час пика: free -h для памяти, uptime для нагрузки на процессор, df -h для диска и docker stats для контейнеров. Одного замера мало, нужны хотя бы несколько дней: пики бывают раз в неделю или раз в месяц.