Каковы основные шаги для диагностики зависания веб-сервиса

Ага, слушай, вот ты сидишь, пьешь кофе, а тут тебе в чат пишут: «Сервис лег, всё встало, блядь». Ну, пиздец, да? Сначала не паникуй, как истеричная мартышлюшка. Надо действовать по плану, а то начнешь тыкаться, как слепой кот в подвале — нихуя не найдешь.

1. Сперва глянь, не уперлась ли система в потолок. Ты ж не на калькуляторе всё запускаешь, вроде. Открывай терминал и смотри, что там у тебя творится.

• Процессор (CPU): Команда top или, если ты не из каменного века, htop. Ищешь процесс, который жрет CPU, как голодный студент дошик. Если какой-то уёбок сидит на 150% — вот тебе и первый кандидат.
• Память (RAM): Тут тоже в top смотришь. Если память под 100%, а своп трещит по швам — привет, утечка памяти. Приложение превратилось в дырявое ведро, блядь.
• Диски (I/O): Запускаешь iotop. Если диск загружен на 100%, а твой сервис что-то яростно пишет или читает — значит, он уперся в этот самый диск, как баран в новые ворота. Всё тормозит, потому что каждая операция ждёт, пока этот тугодумный винт соизволит ответить.
• Сеть: iftop в помощь. Может, твой сервис ушел в запой и скачивает пол-интернета, или наоборот — шлет гигабайты данных куда-то, и все на этом виснут.

2. Теперь читай, что он сам про себя написал. Логи — это как исповедь пьяного друга: в них вся правда, просто надо уметь читать между строк. Лезешь в /var/log/ или юзаешь journalctl -u твой_сервис. Ищешь слова «error», «exception», «timeout», «deadlock». Особенно обрати внимание на те запросы, которые выполнялись дольше, чем сериал «Игра престолов». Вот они-то, сука, и могли всё положить.

3. Если сверху всё вроде чисто, а сервис всё равно висит, как груша — лезем внутрь. Значит, проблема в самой логике, в этом ебучем коде. Тут нужен профилировщик.

Для Питона — два основных пути:

• cProfile: Классика. Встроенный, надёжный, но нужно код немного подготовить. Хорош для тестов.
• py-spy: А вот это, блядь, волшебная палочка для продакшена! Он подключается к уже работающему процессу, не требуя его перезапуска. Никаких изменений в код, чистая магия.

Вот как этим py-spy пользоваться, смотри:

# Ставим эту чудо-утилиту
# pip install py-spy

# Ищем PID нашего пациента
# ps aux | grep my_web_service

# Подключаемся к нему на 60 секунд, как подслушивающее устройство
# sudo py-spy record -o profile.svg --pid 12345 --duration 60

Потом откроешь profile.svg в браузере и увидишь наглядную картину: какая функция сколько времени съела. Сразу станет ясно, кто тут главный тормоз.

А теперь главное — на что обычно натыкаются, как лбом на косяк:

• Блокирующие вызовы в асинхронщине: Это классика, ёпта! Внутри async def какой-нибудь умник написал синхронный запрос к базе или на внешний API. Весь event loop встает колом и ждет, пока этот запрос выполнится. Все остальные запросы в очереди — пиши пропало.
• Взаимные блокировки (Deadlocks): Два потока или процесса схватились, как два барана на мосту. Один говорит: «Дай мне ресурс A, тогда отдам B». Другой: «Нет, ты сначала дай B, тогда отдам A». И стоят так до скончания века. Всё зависло.
• База данных откинулась: Либо запрос такой долгий, что его можно засечь песочными часами, либо в базе самой deadlock случился, и твой сервис просто ждет, пока его отпустят.
• Алгоритмическая тупость: Где-то в коде затесался цикл в цикле, который на маленьких данных работал, а как объем подрос — начал считать со скоростью пьяного ленивца. O(n²) — это не оценка, это приговор для производительности.

Короче, ищи систематично. Не тычь пальцем в небо. Сначала железо и ОС, потом логи, а уж потом лезь в дебри кода с профилировщиком. Иначе так и будешь бегать по кругу, а сервис так и будет висеть, как манда с ушами.