Гайд: Защита сервера от OOM: swappiness, zswap и pagefile для БД и Web без просадок дисков

Гайд по оптимизации памяти сервера. Настраиваем swappiness и zswap в Linux, тюним pagefile в Windows. Защищаем БД от OOM без деградации дисков при пиках.

Гайд: Защита сервера от OOM: swappiness, zswap и pagefile для БД и Web без просадок дисков Параметры swappiness и zswap — это термины и механизмы ядра Linux. В операционной системе Windows их не существует. Windows использует совершенно иную модель управления памятью (файл подкачки pagefile.sys и автоматический менеджмент), и тонкая настройка "жажды" свопа там реализована иначе.

Поскольку в вашем запросе упомянуты специфичные для Linux термины, но указана ОС Windows, я подготовил для вас комплексный гайд.

В Части 1 я расскажу, как решить вашу задачу (защита от OOM без деградации дисков) именно на Windows.
В Части 2 я дам классический гайд по настройке swappiness и zswap для Linux, на случай, если вы имели в виду Linux-серверы или используете гетерогенную инфраструктуру.

ЧАСТЬ 1. Оптимизация памяти и дисков на WINDOWS (Server)

В Windows нет swappiness. Чтобы сервер не упал в OOM (Out of Memory) и диски не "захлебнулись" при пиковых нагрузках, мы настраиваем Файл подкачки (Pagefile) и политики выделения памяти для СУБД.

1. Правильная настройка файла подкачки (Pagefile)

Автоматическое управление размером файла подкачки в Windows Server часто приводит к фрагментации и резким скачкам I/O (дисковой нагрузки), что убивает производительность БД. 1. Откройте Система -> Дополнительные параметры системы -> Быстродействие (Параметры) -> Дополнительно -> Виртуальная память (Изменить).

Снимите галочку «Автоматически выбирать объем файла подкачки».

3. Для Web-сервера: Выберите диск (желательно быстрый NVMe/SSD, не тот, где лежит ОС или БД), выберите Указать размер.

Исходный размер: равен объему ОЗУ (например, 32768 МБ для 32 ГБ ОЗУ).
Максимальный размер: в 1.5 раза больше ОЗУ (49152 МБ). Фиксированный размер предотвращает фрагментацию.

4. Для сервера БД (SQL Server и аналоги): Файл подкачки нужен только для предотвращения краха системы (OOM), но сама БД не должна в него уходить.

Установите фиксированный размер (Исходный = Максимальный). Размер: 8-16 ГБ (этого хватит для системных нужд и предотвращения OOM, но не будет занимать лишнее место на быстром диске).
Разместите его на отдельном быстром SSD/NVMe. Никогда не держите файл подкачки БД на медленных HDD или RAID-массивах с высоким latency.

2. Блокировка страниц в памяти (Lock Pages in Memory - LPIM)

Это критически важная настройка для сервера БД на Windows (особенно MS SQL Server).

Она запрещает ОС выгружать память процесса БД в файл подкачки, гарантируя, что диски не будут использоваться для свопа данных СУБД.

Откройте Локальная политика безопасности (secpol.msc).
Перейдите в: Локальные политики -> Назначение пользовательских прав.
Найдите Блокировка страниц в памяти (Lock pages in memory).
Добавьте туда службу, от которой работает ваша СУБД (например, NT SERVICE\MSSQLSERVER или конкретный доменный аккаунт).
Перезапустите службу БД.

3. Отключение "помощников" Windows (Снижение паразитного I/O)

Чтобы диски не деградировали из-за фоновых задач ОС при нехватке памяти:

Отключите службу SysMain (ранее Superfetch): Она постоянно сканирует диски и использует память. В серверных сценариях (БД/Web) она только вредит.

* services.msc -> SysMain -> Тип запуска: Отключена. 2. Отключите индексирование содержимого на дисках с БД и активными логами Web-сервера (Свойства диска -> Снять галочку "Разрешить индексировать...").

ЧАСТЬ 2. Тонкая настройка swappiness и zswap на LINUX

Если ваши сервера работают на Linux (Ubuntu, Debian, AlmaLinux, Rocky), вот как правильно настроить ядро для защиты от OOM и минимизации дискового I/O.

1. Настройка vm.swappiness

Параметр swappiness (от 0 до 100) определяет, насколько охотно ядро будет выгружать анонимные страницы (рабочую память процессов) в swap по сравнению с очисткой кэша страниц (pagecache).

Для Web-сервера (Nginx, PHP-FPM, Node.js):

Оптимально swappiness=10 или 30. Мы хотим, чтобы кэш файлов сбрасывался, а память процессов уходила в swap только при реальной нехватке.

Для сервера БД (PostgreSQL, MySQL/MariaDB):

Строго swappiness=1 или 10. Никогда не ставьте 0! В старых ядрах 0 полностью отключал swap, что приводило к мгновенному срабатыванию OOM-killer. Значение 1 говорит ядру: "используй swap только в крайнем случае, чтобы избежать OOM".

Применение (временно):

sysctl vm.swappiness=10

Применение (постоянно):

Добавьте в `/etc/sysctl.conf` или создайте файл `/etc/sysctl.d/99-memory.conf`:

vm.swappiness = 10

2. Включение и настройка Zswap

zswap — это легковесный сжатый кэш для страниц свопа. Вместо того чтобы сразу писать страницу на диск (что убивает I/O), ядро сжимает её и кладет в RAM. На диск она уйдет только когда сжатый кэш zswap заполнится. Это кардинально снижает нагрузку на дисковую подсистему при пиках.

Включение и настройка (для ядер 5.x и новее, где zstd работает отлично):

1. Добавьте параметры ядра в загрузчик (GRUB).

Откройте `/etc/default/grub`, найдите строку `GRUB_CMDLINE_LINUX` и добавьте:

   zswap.enabled=1 zswap.compressor=zstd zswap.zpool=z3fold zswap.max_pool_percent=20

Разбор параметров:

zswap.enabled=1 — включаем.
zswap.compressor=zstd — используем zstd (лучшее соотношение скорости и степени сжатия, лучше чем lzo или lz4).
zswap.zpool=z3fold — аллокатор памяти для zswap. z3fold или zsmalloc оптимальны.
zswap.max_pool_percent=20 — сколько % от ОЗУ может занять сжатый кэш. Для БД лучше снизить до 10 или 15, чтобы не отнимать память у самой СУБД. Для Web можно оставить 20.

2. Обновите GRUB и перезагрузите сервер:

   # Для Ubuntu/Debian
   update-grub

   # Для RHEL/Alma/Rocky
   grubby --update-kernel=ALL --args="zswap.enabled=1 zswap.compressor=zstd zswap.zpool=z3fold zswap.max_pool_percent=15"

   reboot

3. Проверьте, что zswap работает:

   cat /sys/kernel/debug/zswap/pool_total_size

(Если число больше 0 и растет при нагрузке — всё работает).

3. Защита критичных процессов от OOM-Killer

Даже с идеальным swap, при жестком дефиците памяти Linux может убить процесс БД. Чтобы защитить СУБД:

Найдите PID вашего процесса БД и понизьте его "шанс" быть убитым:

# Для PostgreSQL
echo -1000 > /proc/$(pidof postgres)/oom_score_adj

# Для MySQL/MariaDB
echo -1000 > /proc/$(pidof mysqld)/oom_score_adj

Значение -1000 полностью запрещает OOM-killer убивать этот процесс. Если памяти не хватит, система уйдет в жесткий swap или зависнет, но процесс БД не будет прерван (что лучше, чем падение и длительное восстановление).

Для автоматизации добавьте это в systemd-юнит вашей БД:

[Service]
OOMScoreAdjust=-1000

Важно:

1. Если у вас Windows:

Забудьте про swappiness. Настройте фиксированный Pagefile на быстром NVMe, отключите SysMain, и обязательно включите Lock Pages in Memory (LPIM) для службы базы данных.

2. Если у вас Linux:

Поставьте vm.swappiness=10, включите zswap с компрессором zstd (ограничив пул до 15-20% RAM), и защитите процесс БД через OOMScoreAdjust=-1000.

Такой подход гарантирует, что при пиковых нагрузках (например, тяжелые выборки в БД или наплыв пользователей на Web) сервер будет использовать сжатие/файл подкачки для сглаживания пиков, диски не будут утилизированы на 100% из-за свопа, а критичные сервисы не упадут от OOM.

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

Статью подготовил: Денис Аверко @Nymexis г. Омск