Утечка памяти

Утечка памяти (memory leak) — ситуация, при которой программа выделяет память для хранения данных, но после завершения работы с ними не возвращает её обратно операционной системе или в пул свободной памяти. Каждый цикл утечки «съедает» небольшой объём RAM. Спустя часы или дни сервер исчерпывает доступную память, процессы начинают использовать своп (swap), производительность падает, и в конечном счёте OOM Killer (Out-of-Memory Killer) завершает процессы принудительно.

Как работает

В языках без сборщика мусора (C, C++) разработчик вручную выделяет память (malloc) и обязан освободить её (free). Если указатель на выделенный блок теряется (переменная вышла из области видимости, была перезаписана), блок становится недостижимым — утечка произошла. Компилятор не может автоматически предотвратить это.

В языках со сборщиком мусора (Python, Java, PHP, Go, JavaScript) явного управления памятью нет, но утечки всё равно возникают: объекты, на которые остаются ссылки (в глобальных переменных, словарях, кешах), не удаляются сборщиком мусора, даже если они больше не нужны. Типичный сценарий для PHP: в long-running процессе (PHP-FPM с keep-alive) или воркере очереди данные накапливаются в статических свойствах класса или глобальных переменных.

На уровне Linux-сервера утечку памяти видно по графику потребления RAM: процесс монотонно занимает всё больше памяти без освобождения. Команда free -h показывает общее потребление, top или htop — потребление по процессам (столбцы RES и VIRT), smem — с учётом разделяемой памяти. Файл /proc/PID/status содержит детальную статистику по конкретному процессу.

OOM Killer — механизм ядра Linux, убивающий процессы при нехватке памяти. Выбирает жертву по алгоритму, учитывающему потребление памяти и «oom_score_adj» (приоритет). В лог ядра попадает запись «Out of memory: Kill process». Перезапуск процесса после убийства OOM Killer временно решает проблему, но не устраняет утечку.

История

Термин «memory leak» появился в документации Bell Labs в 1970-х годах вместе с развитием языка C. С ростом сложности программ утечки памяти стали системной проблемой. В 1992 году создан Purify (Rational Software) — первый коммерческий инструмент поиска утечек. Valgrind как open-source инструмент появился в 2002 году и стал стандартом для C/C++. Garbage collection в Java (JVM, 1995) и автоматическое управление памятью снизили, но не исключили проблему.

Инструменты обнаружения

• Valgrind (C/C++) — запускает программу в эмуляторе и отслеживает каждую операцию с памятью. Находит точное место утечки с стектрейсом. Замедляет выполнение в 5–20 раз.
• AddressSanitizer (ASan) — компиляторный инструмент для C/C++/Rust, добавляет проверки во время компиляции. Замедление 1,5–3x, находит утечки без Valgrind.
• memory_profiler (Python) — построчный профайлер памяти. @profile декоратор показывает потребление каждой строки.
• Xdebug + blackfire.io (PHP) — профилирование PHP-приложений для нахождения аккумулируемых данных.
• top/htop/smem (Linux) — наблюдение за ростом RES (Resident Set Size) процесса во времени.

На что обращать внимание

Мониторинг потребления памяти каждым процессом — обязательная практика для production-серверов. Настройте алерты в системе мониторинга, когда процесс занимает более 80% доступной RAM. Временное решение для PHP-воркеров — ограничение числа обрабатываемых запросов (настройка max_requests в PHP-FPM) перед перезапуском. Для VPS с ограниченным объёмом RAM настройте своп — это даёт время на диагностику вместо немедленного краша OOM.