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

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

❓Вопрос: Что такое Linux PSI (Pressure Stall Information) и как его использовать для мониторинга?

✅Ответ: PSI — это механизм ядра Linux, позволяющий отслеживать давление на ресурсы: CPU, память и I/O. Он показывает, сколько времени процессы провели в ожидании этих ресурсов, что помогает выявить узкие места до того, как ситуация станет критичной (например, до вмешательства oom-killer).

PSI не измеряет загрузку напрямую — он измеряет «stall time» — сколько процессов одновременно не могли продолжить работу из-за нехватки ресурса. Это дает более реалистичную картину деградации системы.

Проверка PSI осуществляется через:

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

Перехват stdout/stderr у systemd-сервиса в рантайме: без перезапуска и strace

Иногда вам нужно отладить запущенный systemd-сервис, чтобы понять, что он пишет в stdout или stderr, но:

– сервис уже работает,
– логи в journald запаздывают или отфильтрованы,
– вы не хотите/не можете использовать strace.

Что делать?

1️⃣Ищем дескрипторы вывода

Узнаём PID процесса:

systemctl show -p MainPID your-service

Идём в /proc/<PID>/fd/ — смотрим, куда пишется stdout (обычно fd 1) и stderr (обычно fd 2):

ls -l /proc/<PID>/fd/1

Может быть что-то вроде:

/proc/<PID>/fd/1 -> /dev/null
или -> socket:[12345]
или -> /run/log/journal/...

2️⃣Если это сокет — дублируем вывод

Можно аккуратно “подключиться” к этому дескриптору с помощью socat, если он всё ещё живой:

socat -u ABSTRACT-CONNECT:your-socket - | cat

Или, если это пайп или лог-файл — можно открыть его напрямую и читать в реальном времени:

tail -f /run/log/your-app.log

3️⃣Переоткрытие stdout/stderr без перезапуска

Иногда вы хотите временно направить stdout/err в другой файл (например, в отладочный лог). Если приложение не закрывает дескрипторы, можно сделать:

exec 3>/tmp/debug.log
sudo tee /proc/<PID>/fd/1 >/dev/null <&3

Это дублирует вывод в debug.log. Подходит не для всех случаев, но может сработать.

Диагностика high-load без perf и strace: ps + procfs как минимум

Когда серверу плохо, а perf, strace и eBPF недоступны (или неуместны) — остаётся old school: ps, top и чтение /proc.

И это вполне достаточно, чтобы найти:

– кто грузит CPU и память,
– где залипли процессы,
– кто блокирует I/O и тормозит остальных.

1️⃣Кто грузит CPU?
Проверяем самых голодных:

ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head

Или top -H — если процесс многопоточный (например, Java или nginx), смотрим нагрузку по тредам.

2️⃣Что делают эти процессы?

Находим PID и лезем в /proc/<pid>/:

cat /proc/<pid>/status | grep -E 'State|VmRSS'

Смотрим состояние (Running, Sleeping, Zombie) и потребление памяти.

Читаем cmdline и cwd:

tr '\0' ' ' < /proc/<pid>/cmdline
ls -l /proc/<pid>/cwd

3️⃣Что с диском?

Находим процессы с активным I/O:

iotop -o    # если доступен

Или вручную:

grep -r . /proc/*/io | grep read_bytes | sort -nk2 | tail

Можно отследить, кто грузит диск даже без iotop.

4️⃣Где залипли?

Иногда процессы висят в ожидании ресурсов. Смотрим wchan:

ps -eo pid,wchan:30,cmd | grep -v -E '^\s*PID' | grep -v running

wchan показывает, где «спит» поток: например, futex_wait_queue_me (ожидание мьютекса) или unix_stream_recvmsg (чтение из сокета).

5️⃣Кто кого держит?

Смотрим locks:

cat /proc/locks

Или проверяем открытые файлы:

ls -l /proc/<pid>/fd/

Быстро даёт понять, кто блокирует файл или ждёт освобождения сокета/канала.

6️⃣А если нагрузка прыгает?

Снимаем срез каждые 5 секунд:

while true; do ps -eo pid,cmd,%cpu,%mem --sort=-%cpu | head -n 10; sleep 5; clear; done

Можно обернуть в watch или bash-циклы для простейшего мониторинга.

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

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

❓Вопрос: Чем отличается fork() от exec() в Linux и когда использовать каждый из них?

✅Ответ: fork() — это системный вызов, создающий новый процесс путём копирования текущего. Получившийся дочерний процесс будет точной копией родительского: он унаследует дескрипторы файлов, переменные окружения и текущее состояние. Основное отличие — у него будет свой PID. Это полезно, если вы хотите создать процесс, который продолжит выполнять ту же программу, но, например, с другими параметрами.

exec() — это семейство функций (execl, execp, execve и др.), которое заменяет текущий процесс на новый, загружая в его адресное пространство другую программу. После вызова exec() оригинальный код процесса больше не выполняется — он полностью замещается. Это удобно, если вы после fork() хотите в дочернем процессе запустить другую программу (что и делает большинство шеллов при запуске команд).