Настройка SWAP на VPS Linux: расширение оперативной памяти

SWAP — это область на диске, куда ядро Linux выгружает страницы памяти, когда физической RAM не хватает. На VDS с небольшим объёмом памяти swap не даёт процессам падать по OOM, но платит за это скоростью: диск в тысячи раз медленнее оперативной памяти.

Создание swap-файла

# Создаём файл 2 ГБ
fallocate -l 2G /swapfile

# Устанавливаем права — swap-файл с открытыми правами ядро откажется использовать
chmod 600 /swapfile

# Форматируем как swap
mkswap /swapfile

# Активируем
swapon /swapfile

# Проверка
swapon --show
free -h

Если fallocate недоступен (редко, на некоторых файловых системах вроде btrfs со сжатием), файл создаётся медленнее, но надёжнее через dd if=/dev/zero of=/swapfile bs=1M count=2048.

Автомонтирование swap при загрузке

# Добавить в /etc/fstab
/swapfile  none  swap  sw  0  0

Без этой строки swap-файл активен только до перезагрузки — после рестарта сервера free -h снова покажет ноль в колонке Swap, и придётся повторять swapon вручную.

Настройка swappiness

# Проверить текущее значение (0-100)
cat /proc/sys/vm/swappiness  # По умолчанию: 60

# Изменить (10 = использовать swap только при острой необходимости)
sysctl vm.swappiness=10

# Постоянно
echo "vm.swappiness=10" >> /etc/sysctl.conf

Значение 60 по умолчанию рассчитано на десктопы, где отзывчивость интерфейса важнее пропускной способности сервера. На VDS с базой данных или веб-сервером ниже значение (10–20) откладывает уход в swap до момента, когда памяти реально не хватает, а не при первой возможности освободить немного RAM под файловый кэш.

Разбор типичных ошибок

Ошибка swapon: /swapfile: insecure permissions 0644, 0600 suggested — ядро предупреждает, что права на файл слишком открытые: без chmod 600 непривилегированный пользователь теоретически может прочитать содержимое swap, а там может оказаться что угодно из памяти других процессов, включая пароли.

swapon: /swapfile: swapon failed: Invalid argument

Эта ошибка обычно значит, что файл не был отформатирован командой mkswap перед swapon, либо файловая система под ним не поддерживает swap-файлы в текущей конфигурации (например, некоторые сетевые ФС или btrfs без специальной подготовки).

Swap заполняется, а RAM при этом свободна — признак не нехватки памяти, а высокого swappiness в сочетании с редко используемыми, но давно висящими в памяти процессами. Ядро может вытеснить их в swap заранее, освобождая RAM под кэш, даже когда прямой необходимости в этом нет. Проверяется через vmstat 1: колонки si/so (swap in/out) должны быть близки к нулю в спокойном режиме, устойчивая ненулевая активность — уже тревожный сигнал.

Рекомендации по размеру SWAP

Zswap как альтернатива обычному swap-файлу

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

# Включить zswap на лету (до следующей перезагрузки)
echo 1 > /sys/module/zswap/parameters/enabled

# Постоянно — через параметр ядра в GRUB
# добавить zswap.enabled=1 в GRUB_CMDLINE_LINUX
update-grub

Zswap не заменяет swap-файл полностью — ему всё равно нужен обычный swap как резервный уровень, он лишь сокращает обращения к нему. Для VDS с 1–2 ГБ RAM и без NVMe-диска это обычно даёт заметный выигрыш в отзывчивости под кратковременными пиками памяти.

Когда swap не решает проблему

• Рабочий набор базы данных стабильно больше RAM плюс swap — сервер будет постоянно свопиться под нагрузкой, и правильный ответ здесь не увеличение swap, а апгрейд памяти или оптимизация запросов.
• Диск — сетевое хранилище с высокой задержкой — swap на таком носителе превращает любое обращение к вытесненной странице в операцию с задержкой в десятки миллисекунд, что для интерактивных сервисов ощущается как зависание.
• Процесс регулярно убивается OOM killer ещё до того, как swap успевает заполниться — это означает не медленный, а слишком резкий скачок потребления памяти, и здесь помогает ограничение памяти самого процесса (например, через systemd MemoryMax), а не больший swap.

Проверка результата

1. Убедитесь, что swap виден после перезагрузки, а не только сразу после ручного swapon: перезапустите сервер и выполните free -h снова.
2. Проверьте приоритет и реальное использование: swapon --show покажет заполненность в столбце Used.
3. Сравните значение vm.swappiness до и после правки /etc/sysctl.conf: sysctl vm.swappiness должно вернуть новое значение и после перезагрузки, а не только в текущей сессии.
4. Понаблюдайте за vmstat 1 10 под обычной нагрузкой — устойчивые ненулевые si/so означают, что памяти всё ещё не хватает, и swap-файл лишь смягчает симптом, а не решает первопричину, разобранную в статье про профилирование производительности Linux.