11 вопросов по теме «DevOps: Linux и траблшутинг» на собеседовании

Короткий ответ: Не обязательно. В Linux load average считает не только runnable-процессы, но и задачи в uninterruptible sleep (D-state) — обычно это ожидание дискового или NFS I/O. Load 30 при простаивающем CPU почти всегда означает проблему с I/O, а не нехватку ядер.

Подробно:

1. Особенность Linux — в отличие от других Unix, load average включает D-state задачи. 30 процессов, зависших на мёртвой NFS-шаре, дадут load 30 при нулевом CPU.
2. Ищем D-state — ps -eo state или top: у виновников статус D.
3. Смотрим диски — iostat -x: %util под 100 и большой await = диск захлёбывается.
4. Проверяем NFS — зависший маунт держит процессы в D-state бесконечно.

uptime                       # load: 30.2 29.8 28.5
top                          # %Cpu(s): ... 95 id → CPU ни при чём
ps -eo pid,state,wchan:30,comm | awk '$2=="D"'
iostat -x 1 3                # %util, await по каждому диску
mount -t nfs,nfs4            # есть ли NFS-маунты, живы ли они

⚠️ Частая ошибка: считать load average мерой загрузки CPU и предлагать «добавить ядер». Если load создают D-state задачи, апгрейд CPU не изменит ничего — узкое место в I/O.

Короткий ответ: Ядро считает каждому процессу oom_score — грубо, процент занимаемой памяти — и убивает процесс с максимальным. Скор сдвигается через oom_score_adj (−1000…+1000). Запись об убийстве ищите в логе ядра: dmesg или journalctl -k.

Подробно:

1. Где след — приложение получает SIGKILL и не успевает ничего залогировать; запись оставляет ядро: «Out of memory: Killed process 1234 (java)…».
2. oom_score — примерно доля используемой памяти (RSS + swap): чем больше процесс ест, тем привлекательнее жертва.
3. oom_score_adj — ручной сдвиг: −1000 полностью исключает процесс из выбора, +1000 делает первым кандидатом. Kubernetes ставит Guaranteed-подам −997.
4. cgroup-лимиты — memory limit на cgroup локализует OOM: жертва выбирается внутри группы-нарушителя, а не среди случайных соседей по хосту.

dmesg -T | grep -i 'killed process'
journalctl -k --since '1 hour ago' | grep -i oom
cat /proc/1234/oom_score /proc/1234/oom_score_adj
echo -900 > /proc/1234/oom_score_adj  # или OOMScoreAdjust=-900 в systemd-юните

⚠️ Частая ошибка: искать причину падения в логах приложения. SIGKILL нельзя перехватить — там будет тишина; смотреть нужно лог ядра.

Короткий ответ: Чаще всего либо кончились inode — место есть, а записать метаданные нового файла некуда, — либо вы упёрлись в блоки, зарезервированные под root: ext4 по умолчанию держит ~5% недоступными обычным пользователям.

Подробно:

1. Inode exhaustion — df -i покажет IUse% = 100%. Типичный виновник — миллионы мелких файлов: кэши сессий, почтовые очереди, артефакты сборок. Лечится поиском и чисткой каталога-рассадника; по размеру в df -h его не видно.
2. Резерв под root — df показывает свободные гигабайты, но обычному пользователю ENOSPC, а root пишет успешно — верный признак. Проверить tune2fs -l, уменьшить резерв tune2fs -m 1.

df -h /data     # Use% 95% — место вроде есть
df -i /data     # IUse% 100% → кончились inode
du --inodes -d1 /data | sort -n | tail   # где живут миллионы файлов
sudo tune2fs -l /dev/sdb1 | grep -i 'reserved block'

⚠️ Частая ошибка: остановиться на df -h и заключить «место есть, значит баг приложения». df -i — обязательный второй шаг при любом ENOSPC.

Короткий ответ: Файл всё ещё открыт процессом: rm убирает имя из каталога, но данные живут, пока открыт последний файловый дескриптор. Найти виновника — lsof +L1; вернуть место без рестарта — обнулить файл через /proc/<pid>/fd/N.

Подробно:

1. Механика — место освобождается, когда счётчик ссылок стал 0 И никто не держит fd. df считает такие «удалённые, но открытые» файлы занятыми, du их уже не видит — отсюда классическое расхождение df vs du.
2. Диагностика — lsof +L1 показывает открытые файлы с link count 0: процесс, номер fd и размер.
3. Вернуть место сейчас — truncate через procfs: : > /proc/<pid>/fd/N обнуляет содержимое, не трогая процесс.
4. Чтобы не повторилось — copytruncate в logrotate или сигнал приложению переоткрыть лог (у nginx — kill -USR1).

df -h /var/log && du -sh /var/log   # df видит 50 ГБ, du — нет
lsof +L1 | grep deleted
# nginx 1234 ... 5w ... 53687091200 /var/log/access.log (deleted)
: > /proc/1234/fd/5                 # место вернулось, процесс живёт

⚠️ Частая ошибка: перезапускать сервис в прайм-тайм ради 50 ГБ. truncate через /proc возвращает место мгновенно и без даунтайма.

Короткий ответ: Почти наверняка нет. Linux сознательно занимает «лишнюю» память под page cache — она отдаётся приложениям мгновенно. Смотреть надо на колонку available, а не free; о реальном дефиците говорят swap-in и major page faults.

Подробно:

1. Пустая память — потерянная память — ядро кэширует диск, чтобы повторные чтения шли из RAM, а не с устройства.
2. Реальные признаки дефицита — растущий si в vmstat 1 (swap-in), major page faults, срабатывания OOM-killer в dmesg.

free -h       # смотрим available, не free
vmstat 1 5    # колонки si/so — идёт ли активный своппинг

⚠️ Частая ошибка: «свободной памяти нет — перезагрузим» или сброс кэша через drop_caches. Page cache — это фича: очистка только замедлит систему до повторного прогрева.

Короткий ответ: Зомби — завершившийся дочерний процесс, чей exit-статус родитель ещё не забрал через wait(). От процесса осталась только запись в таблице процессов: ни кода, ни памяти. Поэтому kill -9 бессмысленен — сигнал шлётся тому, что уже мертво.

Подробно:

fork() → работает → exit() → ZOMBIE (запись в таблице процессов)
                                │  родитель вызывает wait()
                                ▼
                             запись удалена (reaped)

1. Причина всегда в родителе — он не вызывает wait()/waitpid() и игнорирует SIGCHLD. Чинится исправлением или рестартом родителя: осиротевшие зомби переходят к init/systemd, который немедленно их пожинает.
2. Ресурсов зомби не ест — ни CPU, ни памяти; занимает только PID и строку в таблице.
3. Когда это проблема — массовая утечка зомби исчерпывает пространство PID (kernel.pid_max): fork начинает отказывать всем процессам на хосте.

ps -eo pid,ppid,state,comm | awk '$3=="Z"'   # кто зомби и кто родитель

⚠️ Частая ошибка: пытаться «убить» зомби сигналами. Единственный путь — заставить родителя вызвать wait() или перезапустить самого родителя.

Короткий ответ: D-state — uninterruptible sleep: процесс находится внутри системного вызова и обычно ждёт I/O (мёртвая NFS-шара, умирающий диск). Сигналы, включая SIGKILL, доставляются только по возвращении из syscall — пока I/O не завершится или не оттаймаутится, убить процесс невозможно.

Подробно:

1. Это защита, а не баг — прерывание процесса посреди операции с ядром и железом оставило бы структуры данных в неконсистентном состоянии.
2. Смотрим, где застрял — cat /proc/<pid>/stack (стек в ядре) и колонка wchan в ps: функция ядра, в которой спит процесс, указывает на подсистему — NFS, block layer.
3. Лечим причину, а не процесс — поднять NFS-сервер, umount -f / umount -l для мёртвой шары, проверить диск: dmesg на I/O errors, SMART.
4. Если I/O не вернётся никогда — процесс освободит только перезагрузка.

ps -o pid,state,wchan:32,comm -p 1234   # в какой функции ядра спит
cat /proc/1234/stack                    # kernel-стек (нужен root)
dmesg -T | tail -30                     # ошибки диска, NFS-таймауты

⚠️ Частая ошибка: эскалация kill → kill -9 → «почему не работает?!». SIGKILL здесь бессилен by design — искать нужно зависший I/O, а не более сильный сигнал.

Короткий ответ: strace — трассировка системных вызовов: отвечает «на чём процесс висит, какие файлы и сокеты трогает». perf — сэмплирующий CPU-профайлер: отвечает «куда уходят такты». strace через ptrace замедляет цель в разы — на проде с осторожностью; perf стоит единицы процентов.

Подробно:

strace -f -tt -T -p 1234    # живой поток syscalls с таймингами
strace -c -p 1234           # сводка: счётчики и время по вызовам
perf top -p 1234            # горячие функции прямо сейчас
perf record -g -p 1234 -- sleep 30 && perf report   # профиль со стеками

⚠️ Частая ошибка: повесить strace на нагруженный прод-сервис «просто посмотреть» — латентность может вырасти на порядок. Для вопроса «куда уходит CPU» сначала perf; strace — прицельно и коротко.

Короткий ответ: Сначала понять, в какой лимит упёрлись: per-process (ulimit -n / LimitNOFILE) или системный fs.file-max. Затем посчитать и классифицировать дескрипторы процесса — и найти утечку. Поднимать лимит — только после ответа на вопрос «почему их столько».

Подробно:

1. Какой лимит — у процесса свой: cat /proc/<pid>/limits. Для systemd-сервисов ulimit из шелла не действует — правит LimitNOFILE в юните. Системный потолок — fs.file-max.
2. Сколько открыто — ls /proc/<pid>/fd | wc -l против лимита процесса.
3. Что именно открыто — lsof по процессу: тысячи сокетов в CLOSE_WAIT = приложение не закрывает соединения; тысячи одинаковых файлов = утечка fd в коде.
4. Только теперь лимит — если рост легитимный (нагрузка выросла), поднять LimitNOFILE и при необходимости fs.file-max.

cat /proc/1234/limits | grep 'open files'
ls /proc/1234/fd | wc -l
lsof -p 1234 | awk '{print $5}' | sort | uniq -c | sort -rn | head
systemctl show myapp -p LimitNOFILE
sysctl fs.file-max fs.file-nr

⚠️ Частая ошибка: молча поднять лимит в 10 раз. Если это утечка дескрипторов, вы лишь отложили инцидент — и сделали его разбор тяжелее.

Короткий ответ: iowait — время, когда CPU простаивает, ПОКА у него есть незавершённый дисковый I/O. Это разновидность idle, а не работа. Высокий iowait говорит «нагрузка ждёт диск», но сам по себе не доказывает, что диск — узкое место: подтверждать нужно через iostat -x.

Подробно:

1. Определение — ядро помечает такт как iowait, если ядро CPU свободно, но на нём есть задача, заблокированная на I/O. Будь у CPU другая работа — он бы её выполнял.
2. Следствие №1 — высокий iowait означает запас CPU: такты свободны, добавленная вычислительная нагрузка выполнится.
3. Следствие №2 — на загруженном CPU дисковая проблема прячется: iowait низкий, потому что CPU занят другим, хотя диск так же плох.
4. Подтверждение диска — iostat -x: %util к 100, await заметно выше базовой латентности устройства, растущая очередь aqu-sz. Кто генерит I/O — pidstat -d / iotop.

mpstat 1 5      # %iowait по ядрам
iostat -x 1 5   # %util, r_await/w_await, aqu-sz
pidstat -d 1    # I/O в разрезе процессов

⚠️ Частая ошибка: реагировать на цифру iowait без iostat. iowait — симптом сочетания «нагрузка ждёт I/O при свободном CPU», а не метрика здоровья диска.

Короткий ответ: Сначала сверить df с du: если df видит занятое, а du — нет, место держат удалённые-но-открытые файлы или другие маунты. Дальше сузить каталог через du/ncdu, найти растущие файлы по mtime и проверить типовых подозреваемых: логи без ротации, journald, докер-слои.

Подробно:

1. df vs du — lsof +L1 на удалённые открытые файлы; убедиться, что поверх каталога ничего не смонтировано и не прячет старые данные.
2. Сузить каталог — du -xh -d1 / | sort -h или ncdu -x: флаг -x не даёт уйти на другие файловые системы.
3. Что растёт прямо сейчас — find / -xdev -mmin -10 -size +100M: большие файлы, изменённые за последние 10 минут, почти всегда и есть виновник.
4. Типовые подозреваемые — приложение, внезапно включившее debug-логирование; journald без лимита (journalctl --disk-usage); слои и логи контейнеров (docker system df).

df -h / && du -xsh /                        # сходятся ли цифры
lsof +L1 | grep deleted
du -xh -d1 / 2>/dev/null | sort -h | tail
find / -xdev -mmin -10 -size +100M -ls 2>/dev/null
journalctl --disk-usage && docker system df

⚠️ Частая ошибка: сразу удалять «что-нибудь большое». Пока источник роста не найден, освобождённое место съедается за минуты — сначала найти писателя, потом чистить.