Сколько CPU и RAM нужно серверу: как посчитать, а не гадать

Вопрос «сколько cpu и ram нужно серверу» обычно встаёт в момент, когда открываешь страницу тарифов и видишь десяток вариантов с разницей в цене в разы. Дальше всё решается на глаз: одни берут максимум «про запас» и переплачивают вдвое-втрое, другие экономят на минимальном тарифе и через пару недель разбираются, почему сайт по ночам отваливается без единой строчки в собственных логах. У обоих подходов одна причина - решение приняли, не глядя ни на нагрузку, ни на то, что реально происходит на уже работающем сервере. У задачи есть довольно точный порядок расчёта: сначала прикидываете стартовые цифры по типу нагрузки, потом несколько команд показывают, где прикидка разошлась с реальностью.

Коротко. Начните с типа нагрузки: статическому сайту хватает 1 vCPU и 1 ГБ RAM, WordPress с плагинами и магазином стабильнее себя чувствует на 2 vCPU и 2-4 ГБ, приложению на Node.js или Python обычно нужно 1-2 vCPU и 1-2 ГБ, небольшой базе данных - 2 vCPU и 4 ГБ под буферный кэш, а нескольким Docker-контейнерам вместе - от 4 vCPU и 8 ГБ. Это ориентиры для первого заказа, не финальная цифра. Через несколько дней работы смотрите на сервер напрямую: free -h покажет занятую и доступную память, top/htop - кто именно её ест, vmstat 1 5 - есть ли очередь на CPU и активность свопа. Растущий, не спадающий своп и пропадающие без своей ошибки процессы (это работа OOM killer) - сигнал, что памяти реально не хватает. Ошиблись с тарифом - на KVM это чинится апгрейдом без переустановки, а не покупкой нового сервера с нуля.

С чего начать: что именно будет работать на сервере

Прежде чем сравнивать циферки в тарифах, определите тип нагрузки - он гораздо сильнее влияет на профиль потребления, чем абстрактное «трафик» или «посетители в сутки». У разных задач разное соотношение CPU и RAM, и путать их - обычная причина промаха.

• Статический сайт или лендинг - готовые HTML, CSS, картинки, которые веб-сервер просто отдаёт по запросу. Процессору почти нечего считать, памяти нужно немного.
• WordPress или другая CMS на PHP - на каждый запрос страницы поднимается процесс PHP, который выполняет код и обращается к базе данных. Чем больше параллельных посетителей, тем больше таких процессов работает одновременно.
• Приложение на Node.js или Python (API, телеграм-бот, фоновый обработчик) - обычно один процесс с событийным циклом: он быстро переключается между задачами, но тяжёлые вычисления внутри него на время блокируют весь процесс целиком.
• Небольшая база данных (MySQL, PostgreSQL) - любит память не столько под сами процессы, сколько под буферный кэш: часть часто запрашиваемых данных СУБД держит в оперативной памяти, чтобы не читать с диска каждый раз заново.
• Несколько сервисов в Docker-контейнерах - каждый контейнер это отдельный процесс или группа процессов со своим потреблением; складывать нужно все контейнеры вместе, плюс небольшие накладные расходы самого движка контейнеров.

Сколько CPU и RAM нужно серверу по типу нагрузки: ориентиры

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

Если у вас смешанный случай, например WordPress и небольшой Node.js-сервис для форм на одном сервере - складывайте требования по памяти и берите большее из требований по CPU, а не среднее.

Как посмотреть, сколько сервер реально ест

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

Сначала узнайте, сколько виртуальных ядер вообще видит система:

nproc

Команда выведет одно число, например 2. Не путайте его с «мощностью» - vCPU на VPS обычно являются долями физических ядер хоста, но для планирования параллельности процессов (сколько рабочих процессов PHP-FPM запускать, сколько потоков Node.js кластера поднимать) важно именно это число.

Дальше - память. Команда free показывает, сколько оперативной памяти занято, сколько свободно и сколько зарезервировано под своп; флаг -h переводит байты в мегабайты и гигабайты, чтобы не считать нули вручную.

free -h

Типичный (иллюстративный) вывод выглядит так:

total used free shared buff/cache available

Mem: 2.0Gi 780Mi 190Mi 18Mi 1.1Gi 1.0Gi

Swap: 2.0Gi 0B 2.0Gi

• used - память, которую реально держат работающие процессы прямо сейчас;
• buff/cache - файловый кэш ядра; в отличие от used, ядро мгновенно отдаёт эту память приложению, как только она понадобится, поэтому высокая цифра здесь сама по себе не повод для паники;
• available - оценка, сколько памяти реально можно выделить новому процессу без ухода в своп; на неё и стоит ориентироваться, а не на голую free;
• строка Swap с растущим used - первый тревожный знак, разберём его отдельно ниже.

Чтобы увидеть, какой именно процесс всё это ест, нужен монитор процессов в реальном времени. top есть почти в любом образе Ubuntu из коробки, htop обычно нужно доставить - он удобнее читается и позволяет сортировать колонки стрелками.

sudo apt install htop -y

htop

Внутри увидите список процессов с колонками CPU% и MEM% - по ним сразу видно, кто именно занимает ресурсы: клавиша F6 переключает колонку сортировки, q выходит из программы.

Разовый снимок не показывает тренд - нагрузка могла как раз в эту секунду быть низкой. Команда vmstat с двумя числами снимает несколько показаний подряд с заданным интервалом в секундах и их количеством, и по ним видна динамика, а не случайный кадр.

vmstat 1 5

• первая строка вывода - это средние значения с момента загрузки сервера, а не текущее состояние; ориентируйтесь на строки со второй и далее;
• колонка r - число процессов, готовых считать на CPU прямо сейчас; если она регулярно выше числа из nproc, процессам буквально не хватает ядер и они стоят в очереди;
• колонки si/so - скорость чтения и записи в своп в килобайтах в секунду; ненулевые значения, повторяющиеся из строки в строку, означают активную подкачку прямо сейчас;
• колонка wa - доля времени, когда CPU простаивает в ожидании ввода-вывода с диска; высокое значение говорит скорее о диске, чем о нехватке CPU или RAM.

Своп - тревожный звоночек, а не запасной вариант

Своп (подкачка) - это область на диске, куда ядро Linux временно выгружает редко используемые страницы памяти, когда оперативной памяти не хватает. Задумывался он как страховка от единичных всплесков, а не как постоянный источник памяти: даже на быстром NVMe своп на порядки медленнее настоящей RAM, и как только сервер начинает подкачивать данные регулярно, задержки в приложении растут заметно.

Проверить текущее состояние свопа:

swapon --show

Пример вывода:

NAME TYPE SIZE USED PRIO

/swapfile file 2G 0B -2

Единичный, разовый рост USED, например во время ночного бэкапа - нормально, для этого своп и существует, он подстраховал и отпустил память обратно. Плохой знак - когда USED растёт день за днём и не спадает: это значит, что рабочему набору данных сервера постоянно не хватает оперативной памяти, и своп из страховки превратился в постоянную подпорку. Решение здесь не «увеличить своп», а увеличить саму RAM - апгрейд тарифа, а не файл подкачки побольше.

OOM killer: что происходит, когда памяти не хватило совсем

Если не хватило даже с учётом свопа, в дело вступает OOM killer (out-of-memory killer) - механизм ядра Linux, который принудительно завершает один из процессов, чтобы не рухнула вся система целиком. Жертву он выбирает по внутренней «оценке вредности» (учитывает объём занятой памяти и ряд других признаков) - обычно это самый прожорливый процесс на сервере, но не обязательно тот, что вы бы выбрали сами.

Неприятность в том, что со стороны это выглядит загадочно: процесс просто исчезает, systemd в лучшем случае перезапускает его заново, а в собственных логах приложения - ни строчки об ошибке, потому что его не остановили изнутри, его убили снаружи. Если сервис регулярно и необъяснимо перезапускается, первым делом стоит проверить не его код, а системные логи ядра:

sudo journalctl -k | grep -i "killed process"

Строка вида Out of memory: Killed process 1234 (node) total-vm:... anon-rss:... в выводе - прямое подтверждение, что причина не в баге приложения, а в нехватке памяти на сервере целиком. Здесь тоже правильный ответ - больше RAM, а не перезапуск сервиса вручную ещё раз.

journalctl -k | grep -i killed

Если сомневаетесь - начните с меньшего тарифа

Не обязательно угадывать точную цифру с первого раза. На виртуализации KVM, как у WeaselCloud, апгрейд тарифа обычно сводится к смене конфигурации в панели и одной перезагрузке сервера - переустанавливать систему и переносить данные вручную не нужно, подробный порядок разобран в статье про смену тарифа VPS. Разница с OpenVZ и другими контейнерными форматами в том, что там память и своп ведут себя иначе, а иногда и вовсе бывают «плавающими» - если не уверены, какая виртуализация у вашего сервера, это разобрано в статье KVM или OpenVZ.

Практический вывод: закладывать запас «на будущий рост» в первый заказ не нужно. Берите нижнюю границу по таблице выше, смотрите на free -h и vmstat в первую неделю работы, и повышайте тариф, когда available устойчиво уходит ниже 10-15% или своп начинает расти без остановки - а не когда сервер уже пару раз перезапустил сам себя через OOM killer.

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

Сколько оперативной памяти нужно для сайта на WordPress?

Для небольшого сайта с умеренным набором плагинов и посещаемостью в пределах пары тысяч визитов в день обычно достаточно 2-4 ГБ RAM и 2 vCPU. Каждый параллельный посетитель поднимает отдельный процесс PHP-FPM весом примерно 30-50 МБ, и при заметном трафике или тяжёлых плагинах (конструкторы страниц, кэш-плагины с большими правилами) стоит смотреть на реальное потребление через free -h после недели работы, а не ориентироваться только на минимальную цифру.

Сколько ядер CPU нужно для небольшого VPS?

Для статического сайта или простого API хватает одного vCPU: узкое место там почти всегда память или сеть, а не процессор. Второе ядро становится нужным, как только на сервере одновременно работает несколько процессов, которые могут выполняться параллельно - PHP-FPM с несколькими рабочими процессами, база данных рядом с приложением, несколько Docker-контейнеров.

Что означает своп в выводе free -h?

Строка Swap в free -h показывает размер и занятость области подкачки - резервного пространства на диске, куда ядро выгружает редко используемые страницы памяти при нехватке RAM. Разовый небольшой рост занятости - нормально, а вот устойчиво растущий и не спадающий своп означает, что оперативной памяти серверу систематически не хватает.

Что такое OOM killer и почему он завершает процессы?

OOM killer - это механизм ядра Linux, который принудительно останавливает один из процессов, когда память и своп исчерпаны полностью, чтобы не допустить полного отказа всей системы. Выбирает он жертву по внутренней оценке, обычно это процесс с наибольшим потреблением памяти, поэтому увидеть в логах ядра сообщение о завершении важного сервиса - верный признак того, что серверу не хватает RAM, а не что в самом сервисе есть баг.

Сколько RAM нужно для нескольких Docker-контейнеров?

Для 3-5 небольших сервисов (лёгкий API, база данных, кэш, реверс-прокси) стартовым ориентиром служат 4 vCPU и 8 ГБ RAM, но точная цифра складывается из потребления каждого контейнера по отдельности плюс небольшие накладные расходы движка контейнеров. Проще всего проверить командой docker stats внутри уже запущенных контейнеров - она показывает потребление памяти и CPU по каждому из них в реальном времени.

Можно ли взять маленький тариф VPS и потом увеличить ресурсы?

Да, это обычная и разумная стратегия: угадывать точную цифру с первого раза не обязательно. На серверах с виртуализацией KVM апгрейд тарифа делается через панель управления и требует одной перезагрузки, без переустановки системы и без переноса данных вручную - подробности в статье про смену тарифа VPS.

Коротко

• Стартовая цифра зависит от типа нагрузки: 1 vCPU и 1 ГБ для статики, 2 vCPU и 2-4 ГБ для WordPress, 1-2 vCPU и 1-2 ГБ для Node.js/Python-приложения, 2 vCPU и 4 ГБ для небольшой базы данных, от 4 vCPU и 8 ГБ для нескольких Docker-контейнеров.
• Это ориентиры для первого заказа, а не гарантия - на границе диапазона разумнее взять нижнюю цифру и последить за сервером, чем переплачивать за запас, который может не понадобиться.
• nproc показывает число видимых системе vCPU, ориентируйтесь на него при настройке количества параллельных процессов.
• free -h - колонка available надёжнее голой free: это реальная оценка того, сколько памяти можно выделить новому процессу без ухода в своп.
• Высокий buff/cache в free -h - не проблема, это файловый кэш ядра, который мгновенно освобождается по требованию.
• vmstat 1 5 показывает динамику: колонка r выше числа ядер - нехватка CPU, ненулевые si/so из строки в строку - активная подкачка прямо сейчас.
• Разовый скачок в свопе - нормально, устойчиво растущий и не спадающий своп - явный сигнал, что не хватает именно оперативной памяти.
• OOM killer завершает процессы без ошибки в их собственных логах - если сервис необъяснимо перезапускается, сначала проверьте journalctl -k | grep -i killed, а не код приложения.
• На KVM-серверах апгрейд тарифа - это смена конфигурации и перезагрузка, а не переезд на новый сервер, поэтому закладывать большой запас в первый заказ не обязательно.

Что дальше

Общий порядок выбора сервера по задаче, включая диск и сеть, собран в пилар-статье как выбрать VPS. Если не уверены, что за виртуализация стоит за вашим тарифом и как это скажется на памяти и свопе - смотрите разбор KVM или OpenVZ. А для тех, кто ещё выбирает между форматами серверов вообще, есть статья VPS, VDS, облачный и выделенный сервер.