Вопрос «сколько RAM для VPS нужно под мой проект» встаёт перед каждым, кто арендует сервер. Возьмёте слишком мало — сайт начнёт падать под нагрузкой, а процессы будет молча завершать OOM Killer. Возьмёте с избыточным запасом — будете платить за гигабайты, которые простаивают. В этой статье разберём, сколько оперативной памяти сервера реально потребляют типовые задачи — от лендинга и WordPress до баз данных и игровых серверов, — приведём таблицы ориентировочных значений и простую формулу расчёта. Все цифры здесь — практические ориентиры, а не точная наука: реальное потребление зависит от конфигурации, трафика и кода конкретного проекта.
Почему RAM — самый критичный ресурс VPS
Оперативная память — единственный ресурс сервера, нехватка которого приводит не к замедлению, а к отказу. Сравните: при дефиците CPU задачи просто выполняются дольше. При переполнении диска сервис пишет ошибки, но чаще всего продолжает отвечать. А при исчерпании RAM ядро Linux запускает OOM Killer, который принудительно завершает самый «тяжёлый» процесс — как правило, это именно база данных или ваше приложение. Итог: сайт отдаёт ошибку 502, бот молчит, а вы узнаёте об этом от пользователей.
Второй важный момент: свободная память в Linux не простаивает. Всё, что не занято процессами, система отдаёт под дисковый кеш (buff/cache) — повторные чтения файлов идут из памяти, а не с диска. Поэтому «запас» RAM не пропадает зря: он напрямую ускоряет работу сайта и базы данных.
Сколько памяти потребляют типовые компоненты
Прежде чем считать, полезно знать «вес» стандартных кирпичиков серверного стека. Цифры ориентировочные — для настроек, близких к умолчаниям:
| Компонент | Ориентировочное потребление |
|---|---|
| Ubuntu / Debian без графики | 150–300 МБ |
| Nginx | 20–100 МБ |
| PHP-FPM | 30–80 МБ на каждый воркер |
| MySQL / MariaDB (небольшой проект) | 350–800 МБ |
| PostgreSQL (небольшой проект) | 200–500 МБ |
| Redis | от 50 МБ + объём хранимых данных |
| Node.js-приложение | 100–300 МБ |
| Docker-демон (без контейнеров) | 70–150 МБ |
| Панель управления (aaPanel, HestiaCP) | 300–700 МБ |
Обратите внимание на PHP-FPM: память ест не сам сервис, а каждый его воркер. Двадцать воркеров по 60 МБ — это уже больше гигабайта. Как правильно ограничить их количество, мы разбираем в статье об оптимизации PHP-FPM под вашу RAM.
Расчёт RAM под конкретные задачи
Лендинг или статический сайт
Nginx, отдающий статику, — самый лёгкий сценарий: хватит 1 ГБ памяти вместе с системой. Больше здесь решает не RAM, а скорость диска и канала.
Сайт на WordPress или другой CMS
Минимум — 2 ГБ: система, Nginx, несколько воркеров PHP-FPM и MySQL на одной машине. Комфортный уровень — 4 ГБ: остаётся место под кеш опкодов, Redis для объектного кеша и всплески трафика. Если сайт растёт, а плагинов много, закладывайте 8 ГБ — например, тариф Start у Cheap-Host (6 vCPU, 8 ГБ RAM, NVMe) за 450 ₽/мес закрывает типичный WordPress-проект с запасом.
Интернет-магазин или 1С-Битрикс
Здесь память уходит сразу в три места: тяжёлые PHP-процессы, база данных с большим числом товаров и кеширование. Практический ориентир — 8–16 ГБ. Меньше 8 ГБ для магазина с реальным трафиком брать рискованно: пиковые распродажи съедают память быстрее всего.
Выделенная база данных
Для СУБД действует правило «чем больше данных помещается в память, тем быстрее запросы». MySQL держит горячие данные в буферном пуле InnoDB, PostgreSQL полагается на shared_buffers и кеш ОС. Если база заметно больше пары гигабайт — берите 16 ГБ и настраивайте буферы под реальный объём данных.
Telegram-боты, парсеры, скрипты
Python- или Node.js-бот с базой SQLite обычно укладывается в 300–500 МБ. Для таких задач не нужен большой VPS: NAT-тарифы Cheap-Host в Германии с 1–2 ГБ RAM за 59–99 ₽/мес — как раз этот случай (учтите: IPv4 там общий, а порт 25 закрыт, для ботов это не помеха).
Игровые серверы
Minecraft без модов на небольшую компанию просит 4–6 ГБ, сборки с модами — от 8 ГБ и выше; серверы CS2 или Rust — отдельная история. Подробные ориентиры по играм мы собрали в статье о ресурсах для игровых серверов.
Docker и несколько сервисов
Контейнеры не добавляют заметных накладных расходов на память: считайте сумму всех приложений внутри контейнеров плюс 0,5–1 ГБ на систему и демон Docker.
Формула: считаем с запасом
Универсальный алгоритм расчёта из четырёх шагов:
- Выпишите все сервисы, которые будут работать одновременно, и их потребление в пике (по таблице выше или по замерам).
- Сложите значения и добавьте 150–300 МБ на саму ОС.
- Умножьте сумму на 1,3–1,5 — это запас на всплески трафика, обновления и рост проекта.
- Округлите вверх до ближайшего тарифа.
Пример для WordPress-сайта: система 0,3 ГБ + Nginx 0,1 ГБ + 10 воркеров PHP-FPM × 60 МБ ≈ 0,6 ГБ + MySQL 0,8 ГБ + Redis 0,2 ГБ = 2 ГБ. С коэффициентом 1,5 получаем 3 ГБ — значит, тариф с 4 ГБ пройдёт впритык, а 8 ГБ даст спокойный запас и место под дисковый кеш.
Хорошая новость: ошибиться в меньшую сторону не страшно, если хостер умеет апгрейдить тариф. У Cheap-Host CPU, RAM и диск увеличиваются без потери данных — можно начать со Start за 450 ₽ и перейти на Pro (12 vCPU, 16 ГБ) за 750 ₽, когда проект дорастёт.
Что делать, если памяти не хватает
- Настройте swap. Это страховка от OOM Killer, а не замена RAM: даже на NVMe swap на порядки медленнее памяти. Как его правильно создать и подобрать размер — в статье о настройке swap на VPS.
- Ограничьте аппетиты сервисов. Уменьшите pm.max_children в PHP-FPM, подгоните innodb_buffer_pool_size в MySQL под реальный объём данных, задайте maxmemory для Redis.
- Уберите лишнее. Неиспользуемые панели, почтовые сервисы и агенты мониторинга часто съедают сотни мегабайт.
- Апгрейдите тариф. Если после оптимизации available стабильно на нуле — дальше экономия обходится дороже простоя.
Как проверить реальное потребление памяти
Базовая команда на Ubuntu 24.04:
free -hСмотрите на колонку available — это память, реально доступная приложениям. Колонка free почти всегда мала, потому что остаток занят дисковым кешем, и это нормально.
Топ процессов по потреблению памяти:
ps aux --sort=-%mem | head -n 10Динамика и активность swap (столбцы si/so должны быть по нулям):
vmstat 5Для интерактивного наблюдения поставьте htop: sudo apt install htop. А проверить, не «убивало» ли ядро ваши процессы, можно так:
sudo dmesg | grep -i "out of memory"FAQ
Хватит ли 1 ГБ RAM для сайта?
Для статического сайта или лендинга — да. Для WordPress с MySQL на том же сервере 1 ГБ — работа впритык: любой всплеск трафика или тяжёлый плагин приведёт к нехватке памяти. Комфортный минимум для CMS — 2 ГБ, лучше 4 ГБ и больше.
Заменяет ли swap оперативную память?
Нет. Swap — страховка от аварийного завершения процессов. Даже на быстром NVMe обращение к swap на порядки медленнее, чем к RAM. Постоянная работа со swap — сигнал, что памяти не хватает.
Как понять, что RAM пора добавлять?
Три признака: available в free -h стабильно меньше 15–20% от объёма; ненулевые si/so в vmstat; записи OOM Killer в dmesg. Любой из них — повод оптимизировать сервисы или переходить на тариф с большим объёмом памяти.
Почему free показывает, что почти вся память занята?
Linux отдаёт незанятую память под дисковый кеш (buff/cache). Кеш ускоряет чтение с диска и мгновенно освобождается, когда память нужна приложениям. Ориентируйтесь на колонку available.
Сколько RAM нужно для нескольких сайтов на одном VPS?
Считайте по формуле: сумма пикового потребления каждого сайта плюс запас 30–50%. Ориентир — 1,5–3 ГБ на средний сайт на CMS. Для 4–6 небольших проектов обычно хватает 16 ГБ.
Вывод
Считайте оперативную память сервера от задачи: 1 ГБ — статика и лёгкие боты, 2–4 ГБ — сайт на CMS, 8–16 ГБ — магазин, база данных или несколько проектов, 16+ ГБ — тяжёлые и игровые нагрузки. Складывайте пиковое потребление компонентов, добавляйте запас в полтора раза — и не забывайте, что «лишняя» память работает дисковым кешем, а не простаивает.
Если под вашу задачу нужен сервер — у Cheap-Host есть линейка от 8 до 32 ГБ RAM: Start (8 ГБ) за 450 ₽/мес для одного сайта, Pro (16 ГБ) за 750 ₽/мес для магазина или нескольких проектов, Ultra (32 ГБ) за 1500 ₽/мес для тяжёлых нагрузок. Везде NVMe, KVM с выделенными ресурсами, безлимитный трафик, а сервер выдаётся за 45–60 секунд. Начать можно с младшего тарифа — апгрейд выполняется без потери данных.
