Как работает swap и почему «отключить swap» — плохой совет

MAATRIX

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

Что такое swap на самом деле

Первое заблуждение — считать своп «резервной памятью на случай, если основная закончится». Это не главная его функция. Ядро Linux использует swap постоянно, как часть обычного управления памятью, даже когда до OOM (out of memory) далеко.

Механика простая. Ядро следит, какие страницы памяти процессов используются активно, а какие лежат мёртвым грузом — были выделены давно, тронуты один раз при старте и больше не читаются. Классический пример: демон, который при запуске распарсил конфиг, создал под него структуры и с тех пор к этой памяти не обращается; или буфер, который приложение выделило про запас и использует раз в час. Ядро видит по битам доступа (accessed/referenced), какие страницы «горячие», а какие «холодные», и с некоторой периодичностью пытается вытеснить холодные страницы на диск — в swap.

Зачем это делать, если RAM ещё свободна? Затем, что освобождённое место в физической памяти ядро тут же отдаёт под то, что реально нужно прямо сейчас: под дисковый кэш (page cache), под буферы файловой системы, под свежие аллокации активных процессов. Дисковый кэш — это не «мусор, который можно выкинуть», это ускоритель чтения с диска: то, что уже прочитано и лежит в кэше, не нужно читать заново. Чем больше свободной памяти отдано под кэш, тем реже происходят настоящие обращения к диску за данными, которые уже запрашивались.

То есть swap — это не аварийный клапан, а часть механизма, который перераспределяет ограниченный ресурс (RAM) от неиспользуемых данных к используемым. Небольшое количество занятого свопа на сервере с достаточным запасом памяти — это нормально и даже хороший знак: ядро делает свою работу.

Почему полное отключение swap — плохая идея

Логика «уберём swap — будет только быстрая RAM, без медленного диска» звучит разумно, но у неё есть цена, которую обычно не считают заранее.

Без swap у ядра остаётся куда меньше пространства для манёвра. Как только физическая память подходит к пределу, единственный инструмент, который остаётся в распоряжении ядра — это OOM killer, механизм, который выбирает процесс (по эвристике oom_score) и убивает его, чтобы освободить память. Без свопа этот момент наступает раньше и резче: система не успевает разгрузиться постепенно, вытеснив холодные страницы, — она сразу упирается в потолок.

С включённым swap картина мягче: при росте давления на память ядро сначала выгружает неактивные страницы на диск, освобождая RAM для активных процессов. Да, это может добавить задержку — обращение к выгруженной странице потребует чтения с диска. Но это управляемая деградация производительности, а не внезапная смерть процесса. Разница особенно ощутима на серверах с базами данных, очередями и веб-приложениями: лучше на секунду притормозить редкий запрос, чем потерять процесс, который держал открытые соединения и незакоммиченные транзакции.

Есть и второй момент: некоторые системные утилиты и скрипты обслуживания рассчитывают на наличие swap-раздела или файла и ведут себя непредсказуемо в его отсутствие. Отключать swap «для скорости» — значит убирать инструмент, которым управляет ядро, а не пользователь.

Если на сервере действительно достаточно памяти с большим запасом, swap просто не будет активно использоваться — и вреда от его наличия не будет никакого. А вот если памяти впритык, отключение swap меняет плавную деградацию на резкий OOM в самый неподходящий момент, например под ночным пиком нагрузки, когда никто не смотрит на мониторинг.

vm.swappiness: что этот параметр реально значит

vm.swappiness — не переключатель «свопить/не свопить», а параметр, задающий, насколько охотно ядро выгружает страницы анонимной памяти (данные процессов) в пользу page cache. Значение от 0 до 100 (в современных ядрах можно указывать и до 200), по умолчанию в большинстве дистрибутивов — 60.

Посмотреть текущее значение:

sysctl vm.swappiness

Изменить временно (до перезагрузки):

sudo sysctl vm.swappiness=10

Закрепить постоянно — добавить строку в /etc/sysctl.conf или файл в /etc/sysctl.d/:

vm.swappiness = 10

Важно понимать, что означают крайние значения:

• Низкое значение (например, 1–10) — держи анонимную память процессов в RAM как можно дольше, вытесняй в первую очередь файловый кэш (его проще перечитать с диска заново). Разумно для баз данных, где резидентная память процесса (буферный пул СУБД) должна оставаться в RAM.
• Высокое значение (близко к 100) — не жалей, выгружай анонимные страницы активнее ради места под кэш. Может иметь смысл при большом файловом I/O и множестве фоновых процессов с редко используемой памятью.
• 0 не отключает swap полностью (в современных ядрах гарантии тоже нет), а означает «свопить только когда совсем прижмёт». По эффекту это близко к отключению, но не по факту — механизм всё равно может сработать при нехватке памяти.

Правильного универсального значения нет — это настройка под профиль нагрузки, а не магическое число. Для большинства обычных VPS дефолтные 60 работают нормально; менять их стоит осмысленно, после наблюдения за реальным поведением памяти на конкретной машине, а не «на всякий случай».

Когда swap — это НЕ норма, а тревожный звонок

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

Если в swap лежат холодные, давно не используемые страницы — это штатная работа памяти, описанная выше. Проблема начинается, когда система вынуждена выгружать и активно используемую память: то, к чему процессы обращаются прямо сейчас, регулярно, десятки раз в секунду. В этом случае каждое такое обращение превращается в операцию чтения с диска вместо обращения к RAM, а диск на порядки медленнее памяти. Именно это создаёт эффект «всё резко зависло»: не сам факт наличия swap, а постоянный своппинг активных страниц (так называемый thrashing).

Практические признаки того, что дело плохо:

• I/O wait в top/vmstat растёт синхронно со временем отклика приложения;
• в vmstat столбцы si (swap in) и so (swap out) ненулевые постоянно, а не разово;
• приложение тормозит именно в моменты роста занятого swap, а не независимо от него;
• рабочий набор (working set) процессов физически больше, чем есть RAM.

В этом случае диск действительно стал узким местом — но решение не «отключить swap», а разобраться, почему рабочему набору не хватает памяти: либо памяти в принципе мало для нагрузки, либо приложение аллоцирует больше, чем нужно (утечка или неоптимальные настройки), либо стоит пересмотреть конфигурацию сервисов (буферные пулы СУБД, лимиты воркеров и т.п.).

Как посмотреть, что реально свопится

Прежде чем делать выводы, стоит собрать факты, а не судить по одному числу из free -h.

Общая картина активности своппинга — vmstat с интервалом:

vmstat 2 10

Колонки si и so показывают страницы, читаемые из swap и записываемые в swap за секунду. Если они почти всё время нулевые с редкими всплесками — беспокоиться не о чем. Если ненулевые постоянно — там что-то активно выгружается и подгружается обратно, стоит копать дальше.

Сколько именно свопит конкретный процесс — через /proc:

grep VmSwap /proc/*/status 2>/dev/null | grep -v "0 kB"

Покажет PID-ы процессов с ненулевым VmSwap. Дальше по PID можно посмотреть, что это за процесс:

ps -p <PID> -o pid,comm,%mem,vsz,rss

Более наглядно, с разбивкой по процессам — утилита smem (если не установлена: apt install smem / dnf install smem):

smem -tk

Покажет колонки USS, PSS, RSS и swap по каждому процессу — удобно увидеть сразу, кто именно держит данные в свопе и сколько.

Долгосрочная статистика — если установлен sysstat, история через sar:

sar -W 1 5

Покажет частоту swap in/out за интервал — полезно, если проблема плавающая.

Что диск делает при этом — параллельно смотрите загрузку диска:

iostat -x 2

Если %util диска близок к постоянным высоким значениям одновременно с активным swap in/out — это признак, что диск стал узким местом именно из-за своппинга, а не по другой причине (логи, бэкапы).

Смотреть эти метрики стоит не разово, а в динамике — один снимок free -h с ненулевым Swap ни о чём не говорит, важна именно активность (si/so).

Как настроить swap разумно

Практические рекомендации, которые работают лучше, чем крайности «выключить» или «не трогать вообще»:

1. Держите swap включённым размером, адекватным объёму RAM и профилю нагрузки — тема отдельного разговора про правильный размер swap для VPS: чем меньше физической памяти, тем относительно больше должен быть запас в свопе.
2. Настройте vm.swappiness под задачу, а не оставляйте бездумно дефолт и не выкручивайте в 0 «для скорости». Для сервера с СУБД, где важно держать резидентные структуры в RAM, разумно снизить значение до 10–20 и понаблюдать за поведением под реальной нагрузкой.
3. Мониторьте активность, а не факт наличия свопа. Алерт стоит настраивать не на «Swap > 0», а на устойчивый рост si/so в течение времени — это сигнал настоящей проблемы.
4. Если своп активно используется активными данными — это симптом нехватки памяти, а не повод убрать инструмент, который её сглаживает. Реакция — добавить RAM или оптимизировать потребление приложениями; подробнее о диагностике — в статье что делать при нехватке RAM.
5. Разместите swap на быстром накопителе. Если своппинг происходит регулярно даже в штатном режиме, лучше NVMe, чем медленный сетевой диск. Если не уверены, какой диск установлен, проверьте — см. как проверить медленный диск на VPS.
6. Используйте swap-файл, а не только раздел — его проще увеличить или уменьшить на лету без переразметки, при близкой производительности на современных файловых системах.

Отдельно стоит упомянуть zram и zswap — механизмы сжатия страниц в памяти перед (или вместо) записи на диск, снижающие нагрузку на реальный диск ценой затрат CPU на сжатие. Насколько это оправдано, зависит от того, чего на сервере больше — свободных ядер или дискового I/O; универсального ответа тут нет, и присваивать этому решению точные цифры выигрыша без замера на своей нагрузке не стоит.

Частые вопросы