Сервер на 4 ГБ RAM: рабочая настройка без угадывания

На сервере с 4 ГБ RAM один прожорливый процесс способен вытеснить базу данных, а жёсткий лимит памяти — остановить приложение посреди запроса. Ниже — практический план для небольшого веб-сервера на Debian 12 с systemd 252 и cgroup v2: что измерять, какие рычаги крутить и как понять, что вы не сделали хуже.

Сначала найдите пик, а не свободную память

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

Снимите показатели в период, когда сайт действительно загружен: запустите free -h, swapon --show, vmstat 1 и systemd-cgtop. Последняя команда показывает потребление по группам systemd, поэтому удобнее для поиска виновника, чем список отдельных процессов. В vmstat следите за столбцами si и so: регулярный обмен памятью со свопом вместе с замедлением запросов — повод разбираться, а не просто добавлять своп.

Проверьте, что примеры ограничений ниже применимы к вашей системе: команда systemd --version покажет версию systemd, а stat -fc %T /sys/fs/cgroup должна вывести cgroup2fs. На другом дистрибутиве или при другой иерархии cgroup поведение и доступные параметры могут отличаться.

Три приёма и цена каждого

Уменьшите параллелизм там, где это окупится

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

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

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

Поставьте границы для отдельных сервисов

В systemd можно задать для сервиса уровень, после которого система начнёт активнее сдерживать потребление, и верхний предел. Ниже — синтаксис drop-in-файла для приложения с именем myapp.service. Значения только пример: подставляйте свои после замеров, а не копируйте их как рецепт для любого приложения.

[Service]
MemoryHigh=900M
MemoryMax=1100M

Создайте каталог /etc/systemd/system/myapp.service.d/, сохраните содержимое в файле limits.conf внутри него и примените настройки:

sudo systemctl daemon-reload
sudo systemctl restart myapp
systemctl show myapp -p MemoryHigh -p MemoryMax -p MemoryCurrent

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

Термин. Cgroup — механизм Linux, который группирует процессы и позволяет учитывать или ограничивать их ресурсы вместе. В этом примере systemd задаёт лимиты cgroup для одного сервиса.

Своп — страховка, а не четвёртый гигабайт RAM

Сначала проверьте, есть ли своп, командой swapon --show. Если он настроен, не считайте его частью быстродействующей памяти: при активной подкачке сервер может заметно замедлиться, даже если приложения формально не завершились. И наоборот, отсутствие свопа не исправляет нехватку RAM — оно лишь меняет последствия пика.

Смотрите на своп вместе с задержками и показателями vmstat, а не по одному числу занятого места. Если обмен идёт постоянно, выясните, какой сервис создаёт пик, уменьшите его параллелизм или перенесите нагрузку. Добавление свопа может дать системе время пережить короткий всплеск, но не превращает постоянно перегруженный VPS в сервер с большим объёмом памяти.

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

Когда настройки уже не спасают

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

Проверьте и ошибки ядра: journalctl -k покажет сообщения ядра, среди них ищите записи об OOM и завершённых процессах. Если срабатывает MemoryMax, причина может быть в локальном лимите сервиса; если память закончилась на уровне машины — пострадать может не только приложение. Разделяйте эти случаи по журналам и метрикам, прежде чем менять конфигурацию.

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

1. Зафиксируйте исходные показатели в часы пик: доступную память, потребление по сервисам, своп и задержки запросов. Проверьте, что замеры относятся к реальной нагрузке, а не к пустому серверу.
2. Найдите один главный источник пикового расхода и измените только один параметр: например, параллелизм приложения или лимит сервиса. Так вы поймёте, что именно повлияло на результат.
3. Повторите замеры после изменения и проверьте журналы на OOM-события. Если память стабилизировалась, но очередь и задержки выросли, уменьшение параллелизма оказалось слишком дорогим.
4. Если своп остаётся активным или сервисы регулярно упираются в границы, планируйте перенос нагрузки или увеличение RAM. Не лечите устойчивую нехватку памяти бесконечным увеличением свопа.

Инвалидация кешей и тонкая настройка конкретной базы данных зависят от стека; здесь мы разбирали распределение памяти на уровне Linux-сервера.