Тихий герой воскресного утра: как bash-скрипт спас нас от OOM Killer

Привет, Хабр! Статья не входила в планы, пишу с чувством лёгкой сюрреалистичности. В воскресенье утром наш основной API-гейтвей пережил маленькую апокалиптическую битву с памятью и выиграл без моего участия. Делюсь с Вами, как небольшой скрипт, на который я не возлагал абсолютно никаких надежд, отработал аварию.

Введение

У нас есть «боевой» сервер api-prod-01. Задача — быть главным API‑гейтвеем: принимает входящие запросы от мобильных приложений и сайта, ответственный за аутентификацию и прочие нужды. На нём работает связка Ngnix и кастомного Python‑приложения на Gunicorn.

Началось всё с типичной проблемы для понедельника, которая случилась в воскресенье… После пятничного деплоя в одном из воркеров Gunicorn начала медленно (но очень «верно»…) утекать память. Безусловно, свободная оперативная память на сервере закончилась, что спровоцировало «пробуждение» линускового OOM Killer (Out‑of‑Memory Killer) — механизм, который убивает процессы, чтобы спасти систему от полного падения. Этот «товарищ» не разбирается, что бьёт и зачем, поэтому вполне мог попасть в критически важные процессы. Фактически, гарантированный «даунтайм».

В пятницу, я словно почувствовал, что стоит перестраховаться и закинуть этот скрипт на сервер (сам скрипт вытащен с личной VPS). Не было каких‑то предпосылок, как и не было уверенности, что в случае «аварии» — скрипт решит проблему. Но всё оказалось наоборот.

Решение

Я не изобретал каких-то сложных систем. Всё, что было нужно — детектировать проблему и дать системе шанс попробовать спасти себя самостоятельно. Логика очень простая:

1. Ловить момент, когда память на исходе (< 100)

2. Принудительно рестартнуть виновный сервис (в моем случае — Gunicorn), который можно подозревать в утечке

3. Детально записать все действия в лог. Это главный отчёт для «разбора полётов», дабы избежать подобное в дальнейшем

Код «тихого героя»:

#!/bin/bash  # Сторожевой пёс для api-prod-01 # Назначение: отслеживает нехватку памяти и перезапускает gunicorn, # предотвращая срабатывание OOM Killer и даунтайм API  set -euo pipefail  # --- Конфиг --- THRESHOLD_MB=100  # Критический порог свободной памяти в МБ SERVICE_NAME="gunicorn-api.service"  # Сервис, который утекает LOG_FILE="/var/log/api-oom-watchdog.log" SERVER_NAME="api-prod-01"  # Имя сервера для логов  # --- Функции --- log_message() {     local message="$1"     echo "[$(date '+%Y-%m-%d %H:%M:%S')] [$SERVER_NAME] $message" | tee -a "$LOG_FILE" }  # --- Логика работы --- log_message "INFO: Start memory check."  # Получаем количество свободной памяти в мегабайтах free_mb=$(free -m | awk '/Mem:/ {print $7}')  if [ "$free_mb" -lt "$THRESHOLD_MB" ]; then     # Тревога! Память на исходе.     log_message "CRITICAL: Free memory is critically low: ${free_mb}MB. OOM Killer is near."     log_message "ACTION: Attempting to restart service '$SERVICE_NAME' to release memory."      # Попытка вежливо перезапустить сервис     if systemctl restart "$SERVICE_NAME"; then         log_message "SUCCESS: Service '$SERVICE_NAME' restarted successfully."                  # Записываем итоговый статус сервиса и памяти после перезапуска         systemctl status "$SERVICE_NAME" --no-pager -l >> "$LOG_FILE"         free -m | awk '/Mem:/ {printf "MEMORY STATUS: Total: %sMB, Used: %sMB, Free: %sMB\n", $2, $3, $7}' >> "$LOG_FILE"                  log_message "INFO: Crisis averted. The API gateway remains online."     else         log_message "FAILURE: Failed to restart '$SERVICE_NAME'. Manual intervention required!"         exit 1     fi else     log_message "INFO: Memory OK. Free: ${free_mb}MB." fi

Разберём основные моменты кода с пояснением:

«Ремень безопасности», предотвращающий выполнение скрипта в неопределенном состоянии:

set -euo pipefail

Где:

• -e — немедленный выход при любой ошибке

• -u — запрет на использование необъявленных переменных

• -o pipefail — возврат кода ошибки пайплайна, не только последней команды

«Умное» определение свободной памяти:

free_mb=$(free -m | awk '/Mem:/ {print $7}')

Где:

• free -m — показывает память в мегабайтах

• awk '/Mem:/ {print $7}' — извлекает именно свободную память (столбец 7)

Мониторинг вместо реакции на аварию:

if [ "$free_mb" -lt "$THRESHOLD_MB" ]; then

Где:

• Скрипт предотвращает, а не исправляет уже случившуюся проблему

• Порог в 100 МБ выбран до предположительного срабатывания OOM Killer

Перезапуск сервиса:

systemctl restart "$SERVICE_NAME"

Где:

• Сервис перезапускается до того, как процессы хаотично умрут от OOM Killer

• Важное уточнение! Это костыльное решение, запущенное «на всякий случай», основанное исключительно на предположениях, что сервис мог съесть всю память

Основа скрипта — логирование:

echo "[$(date '+%Y-%m-%d %H:%M:%S')] [$SERVER_NAME] $message" | tee -a "$LOG_FILE"

Где:

• Временные метки — для анализа закономерностей

• tee -a — вывод в консоль и файл одновременно

• После перезапуска записывает итоговое состояние системы

Примерная схема работы (для лучшего понимания):

[Запуск] -> [Проверка памяти] - [Достаточно?] -> Да -> [Завершение]                              |                              Нет -> [Перезапуск сервиса] -> [Успех?] -> Да -> [Логирование]                                                          |                                                          Нет -> [Тревога] -> [Выход с ошибкой]

Как это работает в действительности?

Главная особенность — скрипт не работает сам по себе, а лишь тихо висит в cron и запускается каждые 5 минут.

crontab -e и добавляем строчку:
*/5 * * * * root /usr/local/bin/api-oom-watchdog.sh

Давайте посмотрим сценарий работы подобного «решения»:

1. 04:00 — скрипт глянул память, свободно 120МБ. «Memory OK», запишет в лог.

2. 04:25 — память кончается из-за утечки в воркере Gunicorn, свободно всего 85МБ, OOM Killer тихо потирает руки.

3. 04:26 — запускается скрипт из cron.

4. Он видит, что 85 < 100 и срабатывает условие. Подробно записывает в лог критическое состояние.

5. Командой останавливает и заново запускает gunicorn-api.service.

6. Память освобождается, OOM Killer грустно засыпает. Скрипт логирует успех, фиксирует статус сервиса и состояние памяти.

7. Nginx продолжал работу, лишь малая часть запросов приходила с ошибкой 502, пока перезапускался Gunicorn. Обошлось без полного даунтайма.

Итог

В понедельник, после пятничного деплоя, на всякий случай первым делом проверил логи и увидел хронологию ночного инциндента. На моё огромное удивление, не было звонков, разбирательств, был лишь отчёт в /var/log/api-oom-watchdog.log, который продемонстрировал героическое мужество и спас меня от ночных звонков.

Этот скрипт — самый настоящий костыль, заброшенный на сервер «на всякий случай». Это не решение, ни в коем случае. Решение — найти и пофиксить утечку памяти в коде. Но данный костыль позволил серверу «остаться на плаву» и дал мне время на спокойный фикс, позволил избежать «сверхурочной» работы ночью.

from cachetools import TTLCache import datetime  # Кеш на 1000 элементов с TTL 1 час session_cache = TTLCache(maxsize=1000, ttl=3600)  def update_user_session(user_id: int, new_data: dict):     """Обновляем данные сессии пользователя"""     # Ключ - ID пользователя     cache_key = f"user_{user_id}"          # PROBLEM: Если ключ уже есть в кеше - мы ДОБАВЛЯЕМ данные,     # но не обновляем время жизни существующей записи правильно     if cache_key in session_cache:         current_data = session_cache[cache_key]         current_data.update(new_data)  # Просто обновляем данные :)         # TTL не обновляется автоматически при таком подходе :)     else:         # Создаем новую запись         session_cache[cache_key] = new_data

from cachetools import TTLCache import datetime  # Кеш на 1000 элементов с TTL 1 час session_cache = TTLCache(maxsize=1000, ttl=3600)  def update_user_session(user_id: int, new_data: dict):     """Обновляем данные сессии пользователя"""     cache_key = f"user_{user_id}"          # SOLUTION: Явно обновляем запись - это сбрасывает TTL     if cache_key in session_cache:         current_data = session_cache[cache_key]         current_data.update(new_data)         # Ключевой момент: перезаписываем значение         session_cache[cache_key] = current_data  # TTL сбрасывается (как оказывается всё просто :) )     else:         session_cache[cache_key] = new_data

P. S. В моей группе в Телеграм разбираем практические кейсы: скрипты (Python/Bash/PowerShell), тонкости ОС и инструменты для эффективной работы.