Swap-файл vs swap-раздел: как влияет на SSD и работу в системах с малым ОЗУ

На слабых серверах и миниатюрных VPS наличие подкачки решает всё. Даже базовая установка apt без swap может закончиться «убийством» процессов через OOM-killer.

Но что выбрать: swap-файл или swap-раздел? И главное — как сделать, чтобы не угробить SSD и не словить тормоза?

Что выбрать — swap-файл или swap-раздел?

Swap-раздел исторически считался более «надёжным» вариантом: он выделяется на физическом уровне и не фрагментируется. Но в реальности:
⏺менять его размер сложно (особенно без LVM);
⏺требует переформатирования или изменения разметки;
⏺неудобен в облаках и на VPS.

Swap-файл — более гибкий и удобный. Особенно если:
⏺вы работаете на облаке с единственным диском;
⏺у вас ограниченное место;
⏺нужно быстро изменить размер или выключить swap.

На современных ядрах swap-файл работает почти так же эффективно, как и раздел, особенно если создать его правильно.

Как правильно создать swap-файл

Не используйте dd — он может создать фрагментированный файл:

# Плохо:
dd if=/dev/zero of=/swapfile bs=1M count=1024

Вместо этого:

# Хорошо:
fallocate -l 1G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

В fstab:

/swapfile none swap sw 0 0

Дополнительные улучшения: zswap и zram

Чтобы продлить срок службы SSD и ускорить работу на слабых системах:

Zswap — сжатая подкачка в RAM. Включается одной командой:

echo 1 > /sys/module/zswap/parameters/enabled

Zram — компрессированный swap в памяти. Особенно эффективен на embedded и ARM-устройствах:

modprobe zram
echo lz4 > /sys/block/zram0/comp_algorithm
echo 512M > /sys/block/zram0/disksize
mkswap /dev/zram0
swapon /dev/zram0

Настройка поведения подкачки

Чтобы система не бросалась в swap при любой нагрузке:

sysctl vm.swappiness=10

10–20 — хороший баланс: сначала используется RAM, и только потом swap.

Почему apt не чистит /var/cache/apt — и как это может убить ваш контейнер

На голом Ubuntu-бейзовом контейнере вы устанавливаете пару пакетов, а потом обнаруживаете, что образ раздулся на сотни мегабайт.

Причина почти всегда одна — автоматический кэш deb-пакетов, который apt сохраняет в /var/cache/apt/archives, но не торопится удалять.

Что происходит

При установке пакета:

apt install nginx

apt скачивает .deb в /var/cache/apt/archives, а потом уже ставит. Но не удаляет их, если вы явно не вызвали:

apt clean

или

apt autoclean

Во многих минималистичных контейнерных сборках вы этого не делаете — и копите десятки мегабайт мусора при каждом apt install.

Почему это критично в контейнерах
⏺Образы раздуваются — и занимают в 2–3 раза больше места, чем нужно.
⏺Файловая система в overlayfs не освобождается даже если удалить файл вручную позже. Он всё равно останется в нижнем слое.
⏺Контейнеры могут падать из-за переполнения ограниченного volume или rootfs (особенно в CI/CD).

Как это чинить правильно

Перед завершением сборки — чистите кэш:

apt-get clean
rm -rf /var/lib/apt/lists/*

или в Dockerfile:

RUN apt update && apt install -y \
    curl \
 && apt clean \
 && rm -rf /var/lib/apt/lists/*

Трюк с overlayfs

Если вы уже создали контейнер, в котором /var/cache/apt раздулся, а чистка не помогает — потому что это уже лежит в нижнем readonly-слое — можно:
1️⃣Использовать docker export / import — сохранит только активный слой.
2️⃣ Пересобрать образ с clean’ом до commit.
3️⃣ Смонтировать внешний tmpfs в /var/cache/apt в рантайме:

mount -t tmpfs -o size=100m tmpfs /var/cache/apt

💬 Вопрос на собеседовании для DevOps-инженера

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Что такое systemd-nspawn и как он используется?

✅Ответ: systemd-nspawn — это легковесный инструмент контейнеризации, встроенный в systemd. Он позволяет запускать изолированные окружения, похожие на контейнеры, используя chroot и namespaces.

Ключевые особенности:
— Изоляция через PID, mount, user и network namespaces.
— Интеграция с systemd: контейнер можно управлять как обычным сервисом.
— Поддержка journald и машинного журнала логов.

MTU + TSO/GSO/UDP: когда jumbo frame ломает overlay-сеть

VxLAN, GENEVE и прочие overlay-технологии давно стали стандартом — но часто ломаются на ровном месте.

Один из таких кейсов — «всё работает, кроме какого-то странного трафика, который висит/рвётся/отваливается без объяснения». Виновник — неправильное сочетание MTU, jumbo-фреймов и offload’ов.

Что происходит

При использовании VxLAN поверх обычной сети каждый пакет получает дополнительный заголовок (VxLAN + UDP + IP), что увеличивает размер.

Если интерфейсы или туннельная прослойка не умеют в fragment/reassembly или MTU меньше ожидаемого, пакеты просто начинают теряться.

Особенно часто это бьёт по TCP SYN-ACK и UDP VoIP/QUIC.

Где это проявляется
• SSH зависает после ввода пароля
• веб-приложения внезапно «грузятся вечно»
• мониторинг теряет метрики
• nginx падает в 502 на старте TLS
• kubelet не подключается к apiserver через туннель

Как диагностировать
1️⃣Проверить MTU на всех интерфейсах в цепочке:

ip link show dev eth0
ip link show dev vxlan0

2️⃣ Проверить наличие offload’ов:

ethtool -k eth0 | grep -E '(tso|gso|gro)'

3️⃣ Поймать разрыв через tcpdump — будут видны обрезанные пакеты или ICMP fragmentation needed (не всегда!):

tcpdump -i vxlan0 -n -s 0 -vvv

4️⃣ Визуально ловить баги через ping -M do:

ping -s 8972 -M do <ip>

Как лечить
⏺Убедитесь, что внутренний MTU на overlay-интерфейсах (vxlan0, flannel.1 и т.п.) занижен хотя бы на 50 байт.
⏺Отключите GSO/TSO, если видите нестабильность:

ethtool -K eth0 gso off tso off

⏺Используйте sysctl для отключения Path MTU discovery в VxLAN:

sysctl -w net.ipv4.ip_no_pmtu_disc=1

⏺Проверяйте наличие проблемных маршрутов:

ip route get <destination>

TCP FIN_WAIT2 как зомби: кто на самом деле виноват

Когда сервер задыхается от тысяч FIN_WAIT2, первая реакция — «приложение не закрывает сокет». Но в реальности всё сложнее.

Это состояние — часть TCP state machine, в которой соединение уже завершено с одной стороны, но другая не закрыла свой конец. И залипнуть в нем можно надолго.

Что такое FIN_WAIT2?

После того как приложение вызывает close() на сокете, TCP-стек отправляет FIN и попадает в FIN_WAIT1. Как только получает ACK, соединение переходит в FIN_WAIT2. Ожидается, что вторая сторона тоже закроет соединение и отправит свой FIN.

Но если этого не происходит — соединение залипает. ОС ждёт. Иногда — вечно.

Где зарыта проблема?

1️⃣Клиент не закрывает соединение
Часто виновник — клиентское приложение, которое “забывает” вызывать close(), особенно если сессия рвётся без ошибок.

2️⃣ Сервер не настраивает таймауты FIN_WAIT2
Linux по умолчанию может держать FIN_WAIT2 бесконечно, если сокет уже передан в userspace.
Проверить:

sysctl net.ipv4.tcp_fin_timeout

Но это работает только для сокетов, не переданных в userspace. Если accept() уже был вызван — ядро не может удалить соединение самостоятельно.

3️⃣ Не освобождается сокет в приложении
Даже если вы вызываете close(), соединение может оставаться активным, если сокет всё ещё держится в дескрипторах. Проверить можно так:

lsof -nP | grep TCP | grep FIN_WAIT2

Как диагностировать
• Посмотреть, кто держит соединения:

ss -o state fin-wait-2 '( sport = :443 )'

• Локализовать виновника через lsof и netstat -p
• Проверить tcp_fin_timeout, tcp_keepalive_time и поведение приложения

Как лечить
⏺Явно закрывайте соединения на клиенте, особенно если используете keep-alive
⏺Включите tcp_tw_reuse и tcp_tw_recycle с осторожностью (лучше нет)
⏺На стороне сервера: оберните close() в таймер или настройте logic shutdown после inactivity
⏺Для embedded/ограниченных систем: можно использовать iptables для отсечения FIN_WAIT2 через conntrack timeout

Вместо вывода

FIN_WAIT2 — это не баг, а следствие честной реализации TCP. Но в проде оно ведёт к исчерпанию ресурсов и зомби-соединениям. Решение — всегда баланс между корректным shutdown и агрессивным таймаутом.

Лимиты systemd: что произойдёт, если запустить 20k сервисов одновременно

Запустить 20 000 systemd-юнитов — звучит безумно, но на самом деле это вполне достижимо на современной машине. Вопрос в другом: где начнёт всё сыпаться?

Мы сгенерировали 20k простых сервисов с шаблоном ExecStart=/bin/sleep infinity, и попытались запустить их разом через systemctl start test@{1..20000}.

На что упёрлись:

1️⃣PID limits:
Первое, что кончилось — лимит процессов. Даже при ulimit -u unlimited, ядро имеет предельный pid_max. Проверить можно:

cat /proc/sys/kernel/pid_max

2️⃣File descriptors:
Каждый сервис тянет за собой файловые дескрипторы: сокеты, логирование через journald, pipe’ы.
Мониторить:

lsof | wc -l  
cat /proc/sys/fs/file-nr

3️⃣Cgroups:
systemd создаёт по cgroup на каждый юнит. При большом количестве можно уткнуться в лимит вложенности или число control group’ов.
Проверка:

systemctl status test@19999
cat /proc/self/cgroup

4️⃣journal:
Если сервисы пишут в журнал, journald начинает лагать или просто отваливается. Особенно, если RateLimitInterval не сконфигурирован.
Проверить, сколько записей в секунду:

journalctl -o short-precise -f

5️⃣CPU scheduler:
Если юниты зависают или выходят с ошибкой, systemd тратит кучу ресурсов на перезапуск. И даже при Restart=no огромный пул сервисов может повлиять на responsiveness системы.

Как наблюдать:
⏺systemd-analyze dump | grep 'Service State'
⏺systemctl list-units | grep test@ | wc -l
⏺top, iotop, pidstat, journalctl — всё идёт в бой.

💬 Вопрос на собеседовании для сисадмина

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Как работает Linux Security Module (LSM) и зачем он нужен?

✅Ответ: LSM — это подсистема ядра Linux, обеспечивающая инфраструктуру для реализации различных политик безопасности. Она предоставляет интерфейсы для внедрения ограничений на уровне ядра, не меняя сам код ядра напрямую.

LSM реализует механизм hook-based security, в котором в ключевые точки ядра встроены хуки. Эти хуки вызываются перед выполнением чувствительных операций (например, доступ к файлу, сетевой сокет или выполнение бинарника), и LSM-расширение решает — разрешить или запретить операцию.

Как найти самый медленный диск в RAID без iostat: только dd и strace

Когда RAID-массив уходит в degraded, и чтение с него начинает тормозить, первым делом хочется открыть iostat или dstat — но что делать, если этих утилит нет, или нужно быстро сориентироваться на минимальной системе?

RAID5 на mdadm, одно устройство помечено как degraded. Хотим понять, какой из оставшихся дисков тормозит, не прибегая к утилитам верхнего уровня.

1️⃣dd по /dev/mdX с отслеживанием времени

dd if=/dev/md0 of=/dev/null bs=4M status=progress

Смотрим, залипает ли на конкретных участках. Если чтение “пульсирует” — скорее всего, где-то один из дисков тормозит при чтении блоков.

2️⃣ strace на dd — трекинг задержек в syscalls

strace -T -e read dd if=/dev/md0 of=/dev/null bs=4M

Параметр -T покажет время, затраченное на каждый системный вызов read(). Если большинство идут быстро (<0.01s), а иногда появляются задержки в 0.2-0.5 секунды — именно в эти моменты диск фризит.

3️⃣ mdadm + cat /sys/block на live-данных
Можно сверить статистику по mdstat, а потом пойти глубже:

cat /proc/mdstat

Затем для каждого устройства в массиве:

for d in sd{a,b,c}; do echo "$d: $(cat /sys/block/$d/stat)"; done

Здесь можно отследить рост времени обработки I/O по полям в /sys/block/*/stat. Если у одного устройства счётчики существенно выше — это он и есть.

smartctl на подозреваемом диске
После того, как нашли “виновника”, имеет смысл проверить его S.M.A.R.T.:

smartctl -a /dev/sdX