Архитектура под 4 ГБ памяти: реальные ограничения

На сервере с 4 ГБ оперативной памяти приложение может начать получать OOM-kill задолго до того, как вы увидите в мониторинге «занято 100%». Часть RAM забирают ядро Linux, файловый кеш, база данных, контейнеры и фоновые процессы. Поэтому архитектура для такой машины начинается не с выбора фреймворка, а с жёсткого бюджета памяти и ограничения параллелизма.

Что именно означает «4 ГБ памяти»

Сначала проверьте, о каком объёме говорит провайдер. 4 GB в тарифе обычно означают 4 000 000 000 байт, то есть примерно 3,73 GiB. В Linux доступный объём дополнительно уменьшается из-за ядра, драйверов, виртуализации и служебных процессов.

Для практического планирования можно считать, что приложению доступно не 4 ГБ, а примерно 3–3,5 GiB. Это не универсальная норма: точная граница зависит от дистрибутива, панели управления, контейнерного рантайма, типа диска и настроек хостинга.

Память приложения — не память процесса

Процесс может показывать большой виртуальный адресный простор, но это не означает, что столько RAM занято физически. Для диагностики важнее RSS — объём страниц процесса, находящихся в оперативной памяти, а в контейнере — текущее потребление cgroup.

Сноска. OOM-kill — завершение процесса механизмом Linux Out-Of-Memory Killer, когда системе или ограниченной группе процессов не хватает доступной памяти. Он не обязан выбрать самый «тяжёлый» процесс: решение зависит от оценки риска и настроек приоритета.

На машине с 4 ГБ памяти главный ресурс — не средняя загрузка, а запас на худший допустимый запрос.

Куда уходит бюджет

Условный сервер с 4 ГБ RAM должен одновременно вместить несколько разных потребителей:

• ядро Linux, systemd, SSH, журналирование, мониторинг и агент резервного копирования;
• reverse proxy, например Nginx, который обычно потребляет мало памяти, но не решает проблему бэкенда;
• процессы приложения: каждый worker может иметь собственную копию части состояния и библиотек;
• СУБД, её shared buffers, рабочие области запросов и файловый кеш ядра;
• очередь задач, планировщик, конвертеры изображений, headless-браузер или другие всплесковые процессы;
• резерв на пиковый запрос, обновление, миграцию и временные файлы.

Не пытайтесь отдать приложению всю свободную RAM. Если оставить нулевой запас, обычный деплой или запрос с большой выборкой может вытеснить сервис, который в среднем работал стабильно.

Модель бюджета для одного хоста

Ниже не обещание, что каждый сервер выдержит такую схему, а стартовая модель для проверки. Перед запуском измеряйте фактическое потребление своих версий и данных.

Если приложение занимает 250 MiB на worker, четыре worker уже требуют около 1 GiB только по RSS. К этому добавятся дочерние процессы, библиотеки, соединения и запросы, которые могут временно выделять память. Поэтому формула «4 ГБ разделить на число процессов» слишком оптимистична: worker не всегда делится памятью с соседями.

Три схемы размещения

На небольшом сервере есть три практических варианта. Выбор зависит от того, что важнее: простота, изоляция или независимое масштабирование.

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

Где архитектура ломается первой

Слишком много worker

Число worker нельзя выбирать только по числу ядер. На 4 ГБ RAM четыре или восемь процессов могут дать хорошую пропускную способность на коротком тесте, но при этом оставить недостаточно памяти для базы и файлового кеша.

Сначала измерьте RSS одного процесса в спокойном состоянии и под типичным запросом. Затем добавьте запас на пик и умножьте на число процессов. Если при увеличении worker время ответа почти не меняется, а память растёт, вы уже купили конкуренцию, а не производительность.

Один тяжёлый запрос

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

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

Фоновые задачи и конвертация

Обработка изображения, PDF, архива или запуск браузера может кратковременно увеличить RSS в разы. Если такая задача запускается внутри web-worker, пользовательский запрос конкурирует с ней за тот же резерв.

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

Как измерять, а не гадать

Снимайте показатели в трёх режимах: после запуска, при обычном трафике и во время пикового сценария. Одного значения «использовано 70%» недостаточно: Linux использует свободную память под файловый кеш, и это не равно утечке.

• Смотрите доступную память, swap и события OOM на уровне хоста.
• Для каждого сервиса фиксируйте RSS, число процессов и количество открытых соединений.
• Сверяйте потребление контейнера с его лимитом, а не только с общим графиком виртуальной машины.
• Повторяйте тест после деплоя: новая библиотека или миграция могут изменить размер worker.
• Проверяйте не только среднее, но и 95-й или 99-й перцентиль памяти, если система мониторинга его поддерживает.

Для корректного замера зафиксируйте версию Linux 6.x, версию runtime, объём базы, число параллельных запросов и сценарий нагрузки. Без этих условий цифра «приложение потребляет 300 МБ» мало что значит.

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

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

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