Сколько RAM нужно серверу под разные задачи

Память — самый частый bottleneck на VPS: её не хватает тихо, а потом процесс убивает OOM-killer. Разбираем, сколько RAM реально нужно под сайт, бота, базу и контейнеры, как измерить потребление и не переплатить за воздух.

От чего зависит объём памяти

RAM — это не «чем больше, тем лучше», а точный расчёт под рабочую нагрузку. Один статический сайт живёт на 512 МБ, а PostgreSQL под аналитику съест 16 ГБ и попросит ещё. Ключевой принцип: считать не пиковую теорию, а сумму резидентных наборов всех процессов плюс запас на кэш файловой системы и всплески трафика.

• Приложение — сам код и его рантайм (PHP-FPM, Node, Python).
• База данных — буферы и кэш занимают большую часть её аппетита.
• ОС и кэш — ядро держит в памяти горячие файлы, и это нормально.
• Запас — 20-30% сверху, чтобы всплеск не привёл к OOM.

Отдельно важна скорость: когда памяти впритык, система начинает свопить на диск, и тут решает носитель. На NVMe у MAATRIX своп деградирует мягче, чем на SATA-дисках у бюджетных провайдеров, но своп — это костыль, а не замена RAM.

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

Ниже — рабочие вилки, проверенные на практике. Это стартовые значения: под нагрузкой смотри реальные метрики.

• Лендинг, статика, небольшой блог — 512 МБ – 1 ГБ.
• WordPress с плагинами — 2 ГБ (1 ГБ — на грани).
• Telegram/Discord-бот — 512 МБ – 1 ГБ.
• Node.js / Python API — 1–2 ГБ на воркер-пул.
• Docker с 3-5 сервисами — 2–4 ГБ.
• PostgreSQL/MySQL средней БД — 4–8 ГБ.
• Локальная LLM 7B в 4 бита — 6–8 ГБ RAM (или VRAM).

Для WordPress почти всегда узкое место — не PHP, а MySQL и объектный кэш. Добавление Redis экономит и CPU, и память при высоком RPS, потому что снимает повторные запросы к базе.

Отдельная история — базы данных. Их аппетит к памяти нелинеен: чем больше RAM отдать под буферный пул (InnoDB) или shared_buffers (PostgreSQL), тем реже база лезет на диск и тем быстрее отвечает. Практическое правило для выделенного сервера БД — отдать под буферы примерно 60-70% всей памяти, оставив остальное ОС и соединениям. Но если на той же машине живёт ещё и веб-приложение, эти доли приходится делить, и тут важно не переусердствовать: раздутый буферный пул на маленьком VPS выталкивает в своп само приложение.

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

Как измерить реальное потребление

Прежде чем докупать память, посмотри, куда она уходит. Быстрый снимок — free в человекочитаемом виде.

free -h

Столбец available важнее, чем free: ядро специально держит кэш, и «занятая» память под кэш мгновенно освобождается под приложение. Топ процессов по памяти:

ps aux --sort=-%mem | head -10

Динамику в реальном времени удобно смотреть в htop — он сразу показывает и swap, и распределение по ядрам.

sudo apt update && sudo apt install -y htop
htop

Swap: страховка, а не замена RAM

Swap — файл или раздел на диске, куда ядро вытесняет неактивные страницы памяти. Он спасает от внезапного OOM, но работать «из свопа» постоянно нельзя: диск в тысячи раз медленнее RAM. Создать swap-файл на 2 ГБ:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Параметр swappiness регулирует, насколько охотно ядро свопит. Для сервера с БД разумно снизить его, чтобы горячие данные оставались в RAM.

sudo sysctl vm.swappiness=10
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf

Как расти без переплаты

Правильная стратегия — стартовать с адекватного минимума и масштабироваться по метрикам, а не по страху. На MAATRIX можно взять тариф от $8/мес, снять реальные графики за неделю через простой мониторинг и апгрейднуться, когда упрёшься в потолок. Апгрейд RAM обычно проходит без переустановки — данные на месте.

Перед апгрейдом проверь, не течёт ли память в самом приложении: часто «мало RAM» — это утечка в Node или незакрытые соединения к БД, а не реальная нехватка. Один рестарт сервиса иногда экономит целый тариф.

Частые ошибки

• Смотреть на free вместо available — пугаться кэша ядра и зря докупать память.
• Отсутствие swap на маленьком VPS — любой всплеск ведёт к убийству процесса.
• Жить из свопа постоянно — это не экономия, а деградация; пора апгрейдить RAM.
• Не лимитировать контейнеры — один Docker-сервис может съесть всю память хоста.
• Игнорировать утечки — растущее потребление без роста нагрузки почти всегда баг.

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