Своп забит, сервер висит

MAATRIX

Сервер отвечает через раз, команды выполняются с задержкой в секунды, а free -h показывает, что swap занят под завязку. Классическая ситуация: своп забит, сервер висит, и каждое обращение к диску вместо памяти тормозит всю систему. Проблема не в самом свопе, а в том, что кончилась оперативная память и система ушла в диск. Ниже пошаговое решение проблемы — как быстро разгрузить память, найти прожорливый процесс и настроить swap так, чтобы он помогал, а не убивал отзывчивость.

Быстрая диагностика: смотрим память и своп

Первым делом оцените реальную картину — сколько занято RAM, сколько swap и насколько активно система свопит. Команда free -h даёт снимок, а vmstat показывает движение в динамике:

# память и своп: сколько занято
free -h
# активность свопинга в реальном времени (колонки si/so)
vmstat 2

Ключевые колонки в vmstat — si (swap in) и so (swap out). Если они постоянно ненулевые и большие, система прямо сейчас активно гоняет страницы между памятью и диском — это и есть причина тормозов. Заодно обратите внимание на колонку wa (iowait) в том же выводе: при активном свопинге она подскакивает, потому что процессор простаивает в ожидании медленного диска. Эта связка — растущие si/so вместе с высоким wa — однозначно указывает, что сервер тормозит именно из-за свопинга, а не по другой причине, и избавляет от лишних догадок. Сам факт, что swap заполнен, ещё не беда: страницы могли осесть туда давно и лежать без движения. Тревожен именно активный свопинг, когда si/so не останавливаются. Если видите такую картину — переходим к разгрузке, а параллельно ищем, кто съел память.

Находим, кто съел память

Заполненный swap — следствие, причина — нехватка RAM. Нужно назвать процесс-виновник. Отсортируйте процессы по потреблению памяти и посмотрите на лидеров:

# топ процессов по памяти
ps aux --sort=-%mem | head -10
# наглядно в интерактиве — сортировка по RES
top   # затем нажмите Shift+M

Смотрите на колонку RES (реально занятая память) и %MEM. Чаще всего лидирует один-два процесса: раздутая база с большим кэшем, приложение с утечкой памяти, слишком много воркеров веб-сервера или PHP-FPM, тяжёлая JVM. Определив виновника, вы понимаете направление: либо ограничить его аппетит настройками, либо у сервера просто мало RAM под эту нагрузку. Утечка памяти проявляется характерно — потребление процесса растёт со временем без причины, и помогает его перезапуск как временная мера.

Экстренная разгрузка

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

# перезапустить прожорливый сервис
systemctl restart имя_сервиса
# очистить swap (только если свободной RAM достаточно!)
swapoff -a && swapon -a

Важное предупреждение: swapoff -a выгружает всё из swap обратно в RAM, и если свободной памяти мало, это добьёт сервер или спровоцирует OOM-killer. Делайте это, только когда память уже освобождена. В самом тяжёлом случае, когда сервер не отвечает вовсе, помогает перезагрузка через панель провайдера — она вернёт систему в рабочее состояние, но не устранит причину, и без настройки проблема вернётся.

Настраиваем swappiness

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

# текущее значение
cat /proc/sys/vm/swappiness
# уменьшить до 10 временно
sysctl vm.swappiness=10
# закрепить навсегда в /etc/sysctl.conf
echo 'vm.swappiness=10' >> /etc/sysctl.conf

Значение около 10 говорит ядру уходить в swap лишь при реальной нехватке памяти, а не про запас. Для серверов баз данных это заметно улучшает отзывчивость. Но помните: swappiness лишь настраивает поведение, он не создаёт память из ниоткуда. Если RAM действительно не хватает под нагрузку, никакая настройка не спасёт — swap на диске в разы медленнее памяти, и активный свопинг всегда будет тормозить.

Своп есть, но его роль ограничена

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

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

Профилактика: чтобы сервер не висел

Устойчивость от свопинга складывается из запаса памяти и разумных настроек. Подберите объём RAM с запасом под реальную нагрузку — с учётом пиков, а не среднего. Ограничьте потребление прожорливых сервисов: задайте лимиты кэша базы, число воркеров, размер кучи JVM, чтобы они не разрастались бесконтрольно. Держите небольшой swap как страховку и следите за активностью свопинга мониторингом.

• Настройте vm.swappiness в район 10 для серверов с базой.
• Ограничьте память базы, воркеров и приложений явными лимитами.
• Держите небольшой swap как подушку, но не как замену RAM.
• Мониторьте si/so — активный свопинг сигнализирует о нехватке памяти.
• Ловите утечки: растущее со временем потребление процесса.

Когда памяти хватает под задачу, swap остаётся тихой страховкой, а сервер отвечает мгновенно. У MAATRIX VPS с запасом RAM доступны в локациях RU, US и UK, с оплатой из России картой или криптой — можно сразу взять конфигурацию под реальную нагрузку и не бороться со свопингом настройками. Для баз данных и тяжёлых приложений достаточный объём памяти — это не роскошь, а условие нормальной скорости.

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