Своп (swap) в Linux: что это, когда нужен и как настроить

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

Swap (своп, подкачка) — это область на диске, которую ядро Linux использует как продолжение оперативной памяти, когда физической RAM не хватает для всех запущенных процессов. Когда системе нужно освободить память, она временно выгружает на диск те страницы данных, к которым процессы обращаются реже всего в данный момент, освобождая RAM для более активно используемых данных.

Идея кажется привлекательной — «бесконечно расширить память ценой места на диске», — но у неё есть принципиальное ограничение: диск, даже самый быстрый NVMe SSD, на несколько порядков медленнее оперативной памяти по времени случайного доступа. Обращение к данным, вытесненным в swap, занимает не наносекунды, как обращение к RAM, а миллисекунды — разница в тысячи раз, которая ощущается как резкое и заметное замедление всего, что зависит от этих данных.

Swap — это подстраховка на случай кратковременного всплеска, а не полноценная замена достаточного объёма оперативной памяти: то, что технически работает, не всегда работает достаточно быстро для реальной нагрузки.

Общая рекомендация в руководствах по настройке производительности Linux-серверов

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

Что происходит, если swap нет вообще

Если на сервере вообще не настроен swap, а физическая память заканчивается, ядро Linux не может выгрузить неактивные данные на диск и оказывается перед выбором: либо отказать в выделении памяти следующему процессу, попросившему её, либо принудительно освободить память, завершив уже работающий процесс. За это отвечает механизм OOM killer (out-of-memory killer) — он выбирает процесс для принудительного завершения по эвристике, учитывающей объём занятой памяти и ряд других факторов.

dmesg | grep -i "killed process"\njournalctl -k | grep -i "out of memory"

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

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

Создание swap-файла на существующем VPS

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

fallocate -l 2G /swapfile

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

dd if=/dev/zero of=/swapfile bs=1M count=2048 status=progress

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

chmod 600 /swapfile\nmkswap /swapfile\nswapon /swapfile

Проверить, что своп действительно подключён и виден системе, можно командой swapon --show или строкой Swap в выводе free -h — на этом этапе своп уже работает, но действует только до следующей перезагрузки сервера, если не закрепить его в конфигурации автозагрузки отдельным шагом.

swapon --show\nfree -h

Постоянное подключение swap через fstab

Файл подкачки, подключённый только командой swapon, пропадёт при следующей перезагрузке сервера, если не прописать его в файле /etc/fstab, который отвечает за автоматическое монтирование файловых систем и подключение swap при каждом запуске системы.

echo '/swapfile none swap sw 0 0' >> /etc/fstab

Формат строки в fstab для файла подкачки короче, чем для обычной файловой системы: путь к файлу, точка монтирования none (у swap физически нет точки монтирования как у обычного раздела), тип swap, опции sw, и два последних числа — dump и fsck order — для swap всегда равны нулю, поскольку резервное копирование и проверку файловой системы к нему не применяют.

После добавления строки в fstab полезно сразу проверить её корректность командой mount -a — она применяет все ещё не смонтированные записи fstab, и если в строке допущена опечатка, ошибка проявится сразу, а не только при следующей реальной перезагрузке сервера, когда её исправление менее удобно.

mount -a\nswapon --show

swappiness: насколько активно система стремится в swap

Параметр ядра swappiness, принимающий значения от 0 до 100, определяет, насколько охотно система выгружает страницы памяти в swap ещё до того, как физическая RAM заканчивается полностью, а не только в момент реальной нехватки. Более высокое значение означает более агрессивное и раннее использование swap, более низкое — систему, которая держится за оперативную память до последнего и прибегает к swap только при действительной необходимости.

cat /proc/sys/vm/swappiness

Значение по умолчанию 60 — разумный компромисс для настольных систем и универсальных серверов общего назначения, но для сервера, на котором крутится преимущественно один ресурсоёмкий сервис вроде базы данных, часто предпочтительнее заметно более низкое значение, например 10, чтобы система старалась максимально дольше держать данные СУБД в оперативной памяти и прибегала к swap только в действительно крайнем случае.

sysctl vm.swappiness=10\necho 'vm.swappiness=10' >> /etc/sysctl.conf

Первая команда меняет значение немедленно, но только до перезагрузки; вторая добавляет параметр в файл конфигурации sysctl, который применяется автоматически при каждом старте системы. Важно понимать, что снижение swappiness не отключает swap полностью и не гарантирует, что он вообще никогда не будет использован, — оно лишь смещает порог, при котором система предпочитает прибегнуть к нему, а не выгружать данные из файлового кэша или ждать реальной нехватки памяти.

Когда небольшой swap — разумная страховка

Небольшой файл подкачки (порядка 1–2 ГБ, а на серверах с достаточным запасом RAM иногда и меньше) оправдан практически на любом сервере как защита от редких, кратковременных всплесков потребления памяти — например, разового фонового скрипта, временно занявшего больше памяти, чем ожидалось, или кратковременного пика посещаемости сайта, который сам по себе быстро проходит.

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

Проверить историю использования swap за период, а не только его моментальное состояние, удобно через vmstat с интервалом или через любую систему мониторинга, ведущую графики метрик во времени, — моментальный снимок free -h в конкретный момент времени ничего не говорит о том, растёт ли использование swap постоянно или это был единичный, уже прошедший эпизод.

vmstat 5 20

Когда активный swap — сигнал нехватки RAM, а не норма

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

В такой ситуации заметное замедление отклика сервера — прямое и ожидаемое следствие, а не побочный эффект, который можно устранить дополнительной настройкой. Дальнейшее увеличение объёма swap-файла в такой ситуации не решает проблему, а лишь отодвигает момент срабатывания OOM killer, оставляя сервер работать медленно вместо того, чтобы честно и быстро сообщить о нехватке ресурса — что зачастую даже хуже для пользователей сайта, чем разовый явный сбой.

Правильная диагностика начинается с определения, какой именно процесс создаёт основную нагрузку на память — командами top или htop с сортировкой по потреблению памяти (клавиша Shift+M), подробно разобранными в отдельной статье про базовый мониторинг сервера. Если это ожидаемый процесс, работающий под реальной пользовательской нагрузкой (например, база данных или PHP-FPM с большим числом воркеров), закономерный вывод — увеличить объём оперативной памяти в конфигурации VPS, а не продолжать наращивать своп или пытаться выжать больше из существующих ограниченных ресурсов.

Особый случай: swap на сервере с базой данных

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

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

Практический вывод для сервера с базой данных: своп там стоит держать скорее как формальную защиту от полного падения при экстремальном, аварийном сценарии, а не рассчитывать на него в принципе. Правильная настройка — подобрать объём оперативной памяти и параметры самой СУБД (например, размер буферного пула InnoDB в MySQL или shared_buffers в PostgreSQL) так, чтобы рабочий набор данных реально помещался в RAM с запасом, а не полагаться на то, что swap незаметно компенсирует нехватку памяти без потери производительности.

free -h\ncat /proc/sys/vm/swappiness

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

Отдельная тонкость для серверов с базами данных — параметр vm.overcommit_memory, который сама СУБД (например, Redis в своих официальных рекомендациях) часто советует выставлять в значение 1, чтобы ядро не отказывало в выделении памяти под операции вроде создания дочернего процесса для сохранения снимка данных на диск, даже если формально свободной памяти в моменте недостаточно — это отдельная настройка ядра, не заменяющая правильный подбор объёма RAM, а дополняющая его для конкретных операций, зависящих от особенностей выделения памяти в Linux.

Чек-лист настройки swap на VPS

Шаг 1. Оцените объём оперативной памяти сервера и его основную роль — для сервера с базой данных или другим ресурсоёмким сервисом лучше ориентироваться на меньший объём swap и низкое значение swappiness, чем для сервера общего назначения.

Шаг 2. Создайте файл подкачки нужного размера командой fallocate (или dd, если fallocate недоступен) и ограничьте права доступа к нему командой chmod 600.

Шаг 3. Разметьте файл под swap командой mkswap и активируйте его командой swapon, затем проверьте результат через swapon --show.

Шаг 4. Добавьте соответствующую строку в /etc/fstab, чтобы swap подключался автоматически при каждой перезагрузке сервера, и проверьте её корректность командой mount -a сразу, не дожидаясь реальной перезагрузки.

Шаг 5. Настройте swappiness под конкретную роль сервера через sysctl и закрепите значение в /etc/sysctl.conf для сохранения после перезагрузки.

Шаг 6. Периодически проверяйте динамику использования swap, а не только его моментальное значение — стабильно растущее использование это сигнал к увеличению объёма оперативной памяти сервера, а не к дальнейшему наращиванию файла подкачки.

Итог: swap — страховка, а не замена достаточной памяти

Файл подкачки — простой и полезный инструмент, который стоит настроить практически на любом VPS в качестве защиты от резких и обычно редких всплесков потребления памяти, вместо непредсказуемого срабатывания OOM killer при их отсутствии. Настройка занимает буквально несколько команд и не требует переразметки диска или перезагрузки сервера.

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

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