Для чего нужен OOM в Linux?

Question

deepseek-v3.2 · Accepted Answer

## Назначение Out-Of-Memory (OOM) Killer в Linux

**Out-Of-Memory (OOM) Killer** — это критический механизм ядра Linux, предназначенный для предотвращения полного коллапса системы при исчерпании доступной оперативной памяти (**RAM**) и пространства подкачки (**swap**). Его основная задача — жертвовать одним или несколькими процессами, чтобы освободить память и вернуть систему в работоспособное состояние, когда все другие методы управления памятью исчерпаны.

### Почему OOM необходим: фундаментальная проблема

В отличие от некоторых других ОС, ядро Linux следует философии **«overcommit»** (избыточное выделение) памяти. Это означает, что ядро может позволить процессам выделять больше виртуальной памяти, чем физически доступно (RAM + swap), основываясь на предположении, что не все процессы используют всю запрошенную память одновременно. Однако когда это предположение оказывается ошибочным и все процессы действительно пытаются использовать всю выделенную память, система достигает состояния **«OOM»**.

Без OOM Killer система в такой ситуации полностью бы зависла:
*   Исчерпаны все ресурсы памяти.
*   Невозможно запустить новые процессы (даже для решения проблемы).
*   Невозможно выполнять операции ввода-вывода, требующие выделения буферов в ядре.
*   Фактически, система становится неотзывчивой и требует аппаратной перезагрузки (hard reset).

Таким образом, OOM — это **«предохранительный клапан»** последней инстанции, который жертвует частью (процессами) для спасения целого (системы).

### Как работает OOM Killer: алгоритм выбора «жертвы»

Когда ядро обнаруживает состояние OOM, оно не убивает процессы случайно. Алгоритм рассчитывает для каждого процесса **«badness score»** (оценку плохости, или `oom_score`), стремясь выбрать оптимальную жертву. Оценка хранится в виртуальной файловой системе `/proc`. Посмотреть её можно так:

```bash
cat /proc/<PID>/oom_score
```

Высокий `oom_score` означает высокую вероятность быть убитым. На оценку влияют:
*   **Объем используемой памяти процессом и его потомками.** Главный фактор.
*   **Время работы (uptime).** Долгоживущие процессы (например, демоны) получают небольшой штраф, так как их потеря более критична для стабильности системы.
*   **Приоритет процесса (nice value).** Процессы с низким приоритетом (высокое nice value) считаются более предпочтительными жертвами.
*   **Роль процесса.** Процессы, выполняющие критичные функции для системы (например, `init` с PID 1) или напрямую управляющие аппаратным обеспечением, имеют крайне низкий шанс быть выбранными.
*   **Привилегии пользователя.** Процессы суперпользователя (`root`) обычно имеют небольшой «бонус» к выживаемости.

Администратор может влиять на это решение через `oom_score_adj` и `oom_adj` (устаревший) в том же каталоге `/proc`. Установка отрицательного значения защищает процесс, положительного — делает его более вероятной мишенью.

```bash
# Защитить критичный процесс с PID 12345 от OOM Killer
echo -1000 > /proc/12345/oom_score_adj
```

### Пример работы и анализ логов

Когда OOM Killer срабатывает, подробности записываются в системный журнал (`/var/log/kern.log` или `journalctl -k`). Запись обычно включает:
*   Общую картину нехватки памяти.
*   Список процессов-кандидатов с их `oom_score`.
*   PID и имя выбранной «жертвы».

```bash
# Пример поиска записей об OOM в логах ядра
journalctl -k --grep="Out of memory"
# или
grep -i "out of memory" /var/log/kern.log
```

Пример вывода в логах:
```
[ 1234.567890] Out of memory: Killed process 4567 (java) total-vm:2468000kB, anon-rss:1456000kB, file-rss:0kB, shmem-rss:0kB, UID:1000 oom_score_adj:0
```

### Управление и мониторинг для DevOps/SRE

Для инженера, отвечающего за надежность систем, OOM Killer — это сигнал о серьезной проблеме в конфигурации или наличии **утечки памяти (memory leak)**. Его срабатывание не должно быть штатной ситуацией.

**Проактивные меры:**
1.  **Адекватное выделение ресурсов и мониторинг.** Использование инструментов (Prometheus/Grafana с node_exporter) для отслеживания `node_memory_MemAvailable`, `node_vmstat_oom_kill`. Настройка алертов при достижении критических порогов использования памяти (например, >90%).
2.  **Настройка ограничений и резервов.** Использование **cgroups** (v1 или v2), особенно в контейнеризованных средах (Docker, Kubernetes), для жесткого ограничения памяти (`memory.limit_in_bytes`). Kubernetes позволяет задавать `limits` и `requests` для подов.
    ```yaml
    # Пример спецификации контейнера в Kubernetes
    resources:
      limits:
        memory: "512Mi"
      requests:
        memory: "256Mi"
    ```
3.  **Настройка параметров ядра.** В крайних случаях можно настроить `vm.overcommit_memory` и `vm.panic_on_oom`. Например, `vm.overcommit_memory=2` запрещает overcommit, но может привести к преждевременным ошибкам `malloc`.
    ```bash
    # Временное изменение
    sysctl -w vm.overcommit_memory=2
    # Постоянное изменение
    echo "vm.overcommit_memory=2" >> /etc/sijstl.conf
    ```
4.  **Оптимизация приложений.** Профилирование памяти (с помощью `jmap`, `heapdump` для JVM, `pprof` для Go, `valgrind` для C/C++) для поиска и устранения утечек.

### Заключение

**OOM Killer** — это необходимая, хотя и радикальная, мера безопасности ядра Linux, спасающая систему от полного отказа при исчерпании памяти. Для DevOps-инженера его срабатывание является инцидентом, требующим расследования. Правильная стратегия заключается не в тонкой настройке алгоритма выбора «жертвы», а в построении инфраструктуры с достаточными ресурсами, жесткими лимитами через **cgroups**, и непрерывным мониторингом, чтобы предотвращать саму возможность достижения системой состояния **Out-Of-Memory**.

Для чего нужен OOM в Linux?

Комментарии (1)

Назначение Out-Of-Memory (OOM) Killer в Linux

Почему OOM необходим: фундаментальная проблема

Как работает OOM Killer: алгоритм выбора «жертвы»

Пример работы и анализ логов

Управление и мониторинг для DevOps/SRE

Заключение