Кейс: «Сервер тормозит, но CPU и RAM в норме». В поисках дискового I/O.

Проблема: Один из наших веб-серверов (Ubuntu + Nginx + PostgreSQL) начал отвечать на запросы очень медленно. Стандартные дашборды в Grafana показывали, что загрузка CPU — 20-30%, использование RAM — около 60%. На первый взгляд, всё в порядке.

Симптомы:

top и htop не показывали процессов, которые бы «съедали» процессор.
Время ответа сайта (TTFB) выросло с 200 мс до 2-3 секунд.
Пользователи жаловались на «зависания» при работе с базой данных.

Диагностика: копаем в сторону дисков
Первая гипотеза: если не CPU и не RAM, значит, проблема в дисковой подсистеме (I/O). Процессы могут простаивать в ожидании, пока диск прочитает или запишет данные.

Шаг 1: top и iowait
Запускаем top и смотрим на строку %Cpu(s). Нас интересует параметр wa — iowait. Он показывал значения 40-50%, что аномально много. Это значит, что процессор почти половину времени ждёт ответа от дисков.

Шаг 2: iotop
Устанавливаем iotop (sudo apt install iotop), чтобы увидеть, какой именно процесс создаёт нагрузку на диск.

Bash

sudo iotop

Картина прояснилась: процесс postgres постоянно что-то писал на диск с высокой скоростью, а также системный процесс jbd2/sda1-8 (журналирование файловой системы ext4) показывал высокую активность.

Ша-г 3: Анализ работы PostgreSQL
Проверка настроек PostgreSQL показала, что уровень логирования был установлен на statement, то есть каждый SQL-запрос писался в лог-файл. Нагрузка на сайт выросла, и база данных генерировала гигантский объём логов, забивая всю пропускную способность диска.

Решение:

Изменили уровень логирования. В postgresql.conf параметр log_statement был изменён с all на ddl. Теперь логируются только изменения схемы, а не каждый SELECT.

Вынесли логи на отдельный диск. В идеальном мире, логи и данные должны лежать на разных физических дисках, чтобы не конкурировать за I/O.

Оптимизировали checkpoint'ы. Увеличили интервалы между checkpoint'ами, чтобы снизить частоту записи «грязных» буферов на диск.

Вывод:
Когда сервер тормозит, а CPU и RAM свободны, — всегда смотрите на iowait. Это «слепая зона» для многих админов. Умение диагностировать дисковые проблемы с помощью iotop и iostat — ключевой навык для поддержания производительности высоконагруженных систем.

#linux #devops #case #postgresql #performance #debug

🔍 Linux: Когда логи молчат — говорит strace

Бывает так: сервис висит, CPU 100%, а в логах (/var/log/... или journalctl) — тишина. Эникейщик перезагружает сервер. Архитектор запускает strace.

strace перехватывает системные вызовы (system calls), которые процесс отправляет ядру. Это рентген для любого приложения.

1. Подключаемся к зависшему процессу:

strace -p 1234

(где 1234 — PID процесса)
2. Смотрим, куда процесс пытается достучаться (файлы): Если приложение падает с "File not found", но не говорит, какой файл ищет:

strace -e trace=open,openat -p 1234

3. Анализируем сетевую активность (без tcpdump): Видим, к каким IP пытается подключиться процесс.

strace -e trace=connect -p 1234

4. Замеряем время выполнения операций (ищем тормоза): Флаг -T покажет время каждого сисколла.

strace -T -p 1234

⚠️ Важно: strace замедляет работу процесса. На тяжелом проде используйте с осторожностью или смотрите в сторону perf.

#linux #debug #strace #cli #troubleshooting

🕰 Linux: Кто убил сервер в 3 часа ночи? (atop)

Утро понедельника. Сервер перезагрузился ночью. Мониторинг показывает дырку в графиках. top и htop показывают текущую картину, где всё спокойно. Как узнать, что произошло в прошлом?

Ваш спаситель — atop. В отличие от htop, он умеет работать как демон и записывать состояние системы (снапшоты) каждые 10 минут.

Как отправиться в прошлое:

# Читаем лог за сегодня (или выберите файл за вчера)
atop -r /var/log/atop/atop_20251215

Управление машиной времени:
* t — шаг вперед на 10 минут.
* T — шаг назад.
* b — прыгнуть к конкретному времени (например, 02:55).

Вы увидите полную картину того момента: какой процесс съел CPU, закончилась ли память (OOM) или диск ушел в полку по IOPS.

Если atop не стоит, ставьте прямо сейчас. Когда сервер упадет в следующий раз, вы скажете себе спасибо.

#linux #troubleshooting #atop #monitoring #debug #logs

🕵️‍♂️ Пятничный лонгрид: Анатомия сбоя. Почему мы чиним следствия, а не причины (и как перестать это делать)

Пятница. 16:45.
Прилетает алерт: «Прод лежит».
У тебя подскакивает пульс.
Руки сами тянутся к консоли, чтобы написать systemctl restart nginx или ребутнуть виртуалку.

🛑 Остановись.Убери руки от клавиатуры.

В 2026 году перезагрузка сервера без понимания причины — это не решение, а уничтожение улик.
Сегодня поговорим о том, что отличает «эникейщика» от Site Reliability Engineer (SRE): искусстве расследования.

1. Правило «Пяти почему» (The 5 Whys)
Мы часто лечим симптомы.
«Упал сервис — подняли сервис».
Это путь к выгоранию, потому что сервис упадет снова, когда ты будешь спать.

Применяй метод Toyota:
Проблема: Упал интернет-магазин (502 Bad Gateway).

1. Почему? PHP-FPM перестал отвечать.

2. Почему? Закончилась оперативная память, пришел OOM Killer.

3. Почему? Один процесс съел 4 ГБ RAM.

4. Почему? Пользователь загрузил картинку размером 50 МБ, а библиотека обработки изображений попыталась разжать её в память.

5. Почему? (Корневая причина): На фронтенде нет валидации размера загружаемого файла, а на бэкенде нет лимитов памяти на воркер.

Решение: Не «добавить памяти серверу», а «поставить лимит на загрузку».

2. Не путай совпадение с причиной (Correlation vs Causation)

«Я обновил ядро, и через час упала база. Наверное, ядро кривое». Возможно. А возможно, именно в этот час запустился «тяжелый» отчет бухгалтерии, который запускается раз в месяц.

Инструмент: В 2026 году мы смотрим на eBPF и трассировку. Не гадай. Используй perf, sysdig или biosnoop. Если ты не видишь, почему процесс встал (ждет диска? сети? мьютекса?), ты просто играешь в лотерею.

3. Теория «Черного ящика» и гигиена логов
Если твой лог выглядит как стена текста INFO: processed item, он бесполезен. В момент аварии тебе нужно знать, что случилось ДО падения.

Правило: Логи должны быть структурированы (JSON). Грепать текст в 2026-м — моветон.

Совет: Настрой ротацию так, чтобы при краше сохранялся coredump или хотя бы последние 1000 строк лога в отдельный файл crash_report_date.log.

🚀 Пятничный ритуал «Закрытия гештальтов»:

Чтобы уйти на выходные и реально отдохнуть, сделай эти 3 действия прямо сейчас:

* Browser Bankruptcy: Закрой эти 50 вкладок с документацией, которые ты «потом почитаешь». Если это важно — добавь в закладки/Obsidian. Если нет — закрой. Освободи RAM своего мозга.

* Clean Desktop: Удали с рабочего стола (и из папки Загрузки) временные скрипты test.sh, sql_dump_new_final.sql и скриншоты ошибок. Цифровой мусор создает тревожность.

* Silence is Golden: Проверь расписание дежурств (On-Call). Если в эти выходные ты не дежурный — выключи уведомления рабочего чата. Совсем. Мир не рухнет, а твоя нервная система скажет спасибо.

Помни: Хороший инженер — это не тот, кто быстро чинит, а тот, кто знает, почему оно сломалось, и делает так, чтобы это не повторилось.

Выдыхаем, коллеги. Эта неделя была долгой, но мы справились. 🍺🔌

#friday #longread #troubleshooting #sre #sysadmin #psychology #admin_future #debug

🧠 Skill: Git Bisect — находим, кто сломал прод, за 5 минут 🕵️‍♂️

Ситуация: вчера деплой Terraform/Ansible работал.
Сегодня утром падает с ошибкой.
За ночь коллеги сделали 50 коммитов.
Читать каждый? Нет.

Используй бинарный поиск по истории git.

Алгоритм действий:

1. git bisect start — начинаем охоту.
2. git bisect bad — говорим: "сейчас всё плохо".
3. git bisect good v1.2 — говорим: "вот в теге v1.2 (три дня назад) всё работало".

Git сам переместит тебя ровно в середину истории. Ты проверяешь (запускаешь план).
Работает? Пишешь git bisect good.
Не работает? Пишешь git bisect bad.

За 4-5 шагов Git найдет тот самый коммит из сотни и покажет автора.

Результат: Ты не гадаешь, а математически точно находишь проблему. Это навык сеньор-уровня. 💎

#git #devops #troubleshooting #skill #versioncontrol #infrastructure #debug

🐧 Linux: strace — твой рентген, когда логи молчат 🩻

Ситуация: скрипт или сервис падает с невнятной ошибкой «Configuration error» или вообще молча закрывается.
В логах пусто, права доступа вроде в порядке.
Как узнать, какой именно файл он пытается открыть и не может?

Не гадай. Используй strace. Он показывает все системные вызовы (обращения к ядру), которые делает процесс.

Команда-детектив:

# -f: следить за дочерними процессами (если скрипт запускает другие)
# -e trace=file: показывать только операции с файлами (open, read, access)
strace -f -e trace=file ./my_broken_script.sh

Что ты увидишь: Вместо тишины ты увидишь правду: openat(AT_FDCWD, "/etc/myconf/secret.cfg", O_RDONLY) = -1 EACCES (Permission denied)

Оказывается, скрипт лезет не в ту папку, о которой ты думал!

Лайфхак для живого процесса: Можно подключиться к уже запущенному зависшему процессу:

sudo strace -p [PID]

Это «God Mode» для отладки, который экономит часы перебора конфигов.

#linux #debug #strace #troubleshooting #sysadmin #devops #kernel