Сервер с 4 ГБ RAM: чек-лист перед продакшеном

Сервер с 4 ГБ RAM может стабильно обслуживать небольшой сайт или API, но запас заканчивается быстро: приложение, PostgreSQL, Nginx, фоновые задачи и сборщик логов конкурируют за одну и ту же память. Этот чек-лист рассчитан на Ubuntu Server 24.04 LTS и типичный стек Nginx + приложение + PostgreSQL 16. Пройдите его до переключения DNS или открытия сервиса для пользователей.

Сначала зафиксируйте границы сервера

Четыре гигабайта — это объём всей виртуальной машины, а не память, которую можно отдать приложению. Часть заберут ядро Linux, файловый кеш, systemd, агенты мониторинга и сам PostgreSQL.

• Запишите объём RAM, число виртуальных CPU и размер диска.
• Составьте список постоянных процессов: веб-сервер, приложение, база, Redis, воркеры, cron-задачи, Docker и агенты наблюдаемости.
• Отделите критичные процессы от временных: резервное копирование, миграции и отчёты не должны запускаться без ограничений.
• Определите максимальную нагрузку: запросы в секунду, число фоновых задач, размер базы и число одновременных соединений.

Проверка на Ubuntu 24.04 LTS:

free -h
nproc
lsblk
systemctl --type=service --state=running

В выводе free -h смотрите не только на строку free. Важнее столбец available: это приблизительный объём памяти, который система может отдать новым процессам без активного вытеснения данных.

Проверьте память без иллюзий

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

free -h
ps -eo pid,comm,%mem,rss --sort=-rss | head -n 15
vmstat 5 12
systemctl --failed

vmstat показывает динамику. Если при нагрузке растут значения подкачки, а в колонках si и so регулярно появляются операции, сервер тратит время на обмен с диском. Для веб-приложения это обычно означает рост задержки, а не безопасное использование «свободного» ресурса.

Swap спасает от немедленного убийства процесса, но не превращает 4 ГБ RAM в 8 ГБ: при активной подкачке приложение продолжает работать, только заметно медленнее.

Выберите стратегию подкачки

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

Размер swap нельзя назначать по старой формуле «в два раза больше RAM». Он зависит от нагрузки, требований к гибернации и места на диске. Для сервера без гибернации задайте размер по результатам теста, а не по универсальному правилу.

swapon --show
cat /proc/sys/vm/swappiness
journalctl -k -b | grep -i -E 'oom|out of memory|killed process'

Если видите Out of memory или Killed process, сначала ищите причину перерасхода и выставляйте лимиты. Простое увеличение swap может лишь отсрочить проблему.

Сноска. OOM killer — механизм ядра Linux, который выбирает и завершает процесс, когда системе не хватает памяти и освободить её обычными способами не удаётся.

Разложите бюджет памяти по сервисам

Главная ошибка на машине с 4 ГБ — запускать все компоненты без верхних границ. У приложения могут быть свои worker-процессы, у PostgreSQL — буферы и соединения, у Docker — несколько контейнеров. В сумме они легко превысят доступный объём.

Приложение и воркеры

Посчитайте память одного процесса после прогрева и умножьте на число процессов. Если один worker занимает 180 МБ, восемь worker-процессов требуют около 1,4 ГБ без учёта веб-сервера и общей памяти. Замеряйте RSS после одинакового сценария, а не сразу после запуска.

Не увеличивайте число worker только потому, что CPU простаивает. На сервере с 4 ГБ лишний worker часто создаёт конкуренцию за RAM и ускоряет переход к swap.

PostgreSQL 16

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

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

Docker и systemd

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

systemctl status your-app.service
systemctl show your-app.service -p MemoryCurrent -p MemoryMax -p Restart
journalctl -u your-app.service -b --no-pager | tail -n 100

Замените your-app.service на имя своего юнита. Если параметр MemoryMax не задан, сервис не имеет явного верхнего предела на уровне systemd.

Уберите источники внезапного расхода памяти

• Логи. Настройте ротацию и срок хранения. Полный диск ломает запись логов и резервное копирование, а чрезмерно подробный лог увеличивает нагрузку на CPU и диск.
• Очереди. Задайте максимальный размер очереди и поведение при переполнении. Бесконечная очередь превращает временный сбой обработчика в накопление объектов в памяти.
• Кеш. Укажите верхний предел или размер хранилища. Кеш без лимита постепенно съедает память, даже если запросы к приложению выглядят нормально.
• Резервные копии. Не держите архив базы целиком в RAM и не запускайте несколько тяжёлых заданий параллельно с пиковым трафиком.
• Мониторинг. Не ставьте несколько агентов, которые собирают одни и те же метрики. Для старта достаточно RAM, swap, load average, диска, задержки и рестартов.

Проведите тест, похожий на продакшен

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

1. Снимите базовые значения: available из free -h, RSS процессов, swap in/out, задержку ответа и число ошибок.
2. Подайте нагрузку ступенями, например от обычного уровня к ожидаемому пику, не пропуская промежуточные значения.
3. Параллельно запустите штатную фоновую задачу: импорт, резервную копию или обработку очереди.
4. Проверьте, не растёт ли память после окончания нагрузки. Утечка проявляется не обязательно в момент пика.
5. Остановите тест при устойчивом росте swap, ошибках OOM, деградации задержки или заполнении диска.

Записывайте условия эксперимента: версию Ubuntu, размер VPS, число CPU, размер базы, количество соединений и длительность. Без этих данных сравнение «до и после» мало что значит.

Что ломается первым

Приложение перезапускается без понятной причины

Проверьте журнал ядра и юнита. Причиной может быть OOM killer, лимит systemd, ошибка самого приложения или политика оркестратора. Не увеличивайте число worker, пока не выяснили, кто именно завершил процесс.

Сервис отвечает медленно, но CPU свободен

Проверьте swap, дисковую задержку и очередь запросов. Свободный CPU не означает наличие памяти: процесс может ждать чтения вытесненной страницы или соединения с базой.

После запуска резервной копии пропадает доступ к сайту

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

Метрики говорят «всё нормально», а пользователи видят 502

Проверьте таймауты Nginx, число занятых worker-процессов, ошибки upstream и лимиты файловых дескрипторов. Память — только один возможный источник 502.

Что делать дальше

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

Если доступная память регулярно падает почти до нуля, swap используется не эпизодически, а задержка растёт, у вас два честных варианта: уменьшить число процессов и фоновых задач либо увеличить тариф. Оптимизация конфигурации может вернуть запас, но не отменяет физический предел 4 ГБ.