Утечка оперативной памяти: как обнаружить?

В статье приводится описание способов вычленения такой проблемы как утечка оперативной памяти. Здесь вы ознакомитесь с тем, как убедиться в том, что утечка по памяти присутствует в Windows, и в чём вероятная причина утечки. Утечка оперативной памяти всегда самый настоящий кошмар для каждого из пользователей. Но среди них прежде всего эта проблема бьёт по разработчикам с одной стороны и по владельцам серверов с другой. Первые сначала разрабатывают “кривое” приложение, на которое впоследствии сыпется куча рекламаций, а вторые мучаются, страдая от лавинообразных потерь в оперативке, в конце концов перезагружая сервера с кучей извинений в адрес клиентов.

Утечка оперативной памяти: и сразу к делу

Первое, в чём стоит убедиться, что в периодических “фризах” Windows виновата действиьельно утечка оперативной памяти. И у вас, вероятно, уже есть подозрение на какой-то конкретный процесс. Мы, обычные пользователи Windows, привыкли использовать для подобных проблем Диспетчер задач. Он, к слову, от версии к версии становится всё удобнее в смысле анализа и вероятных выводов в сторону системных вопросов. Но в свете нашей проблемы, даже развернув столбцы распределения RAM Диспетчера по максимуму…

много полезного из окна мы всё равно не увидим. Дело в том, что Диспетчер задач Windows традиционно отображает рабочий набор памяти (т.е. выделяемой). Но не объёмы реально используемой. В чём разница? Проще говоря, некоторая часть из рабочего набора памяти может работать сразу на несколько приложений. Этот тип памяти получил название Разделяемая (Shared Memory). И вот здесь и начинаются проблемы. И всё потому, что рабочий набор памяти может быть ГОРАЗДО БОЛЬШЕ, чем объём памяти используемой.

Причины утечки

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

• нужно определиться с типом утечки – является ли она управляемой или неподконтрольна
• в чём истинная причина утечки (конечный объект, незакрытый файл какой-то библиотеки и т.п.)
• что за функция или маршрут вызывают утечку?

Кроме того, утечки оперативной памяти вообще принято разделять на две группы:

• утечка в системном ядре (Kernel Mode)
• утечка на уровне пользователя (User Mode)

Исходя из вариантов маршрута, отслеживающего причину и тип утечки, мы можем выбрать вариант как безошибочно определить “пакостное” приложение.

Утечка оперативной памяти: а вам не показалось?

Чтобы более-менее точно определить размер памяти, которая расходуется программой, нужно отслеживать байты исключительного пользования –закрытые байты памяти (private bytes) для приложения. Этот счётчик будет считать объём памяти, которое потребляется именно приложением; совместной памятью они не будут использоваться. С них и начнём. Закрытые байты – это те участки памяти, которые системой остальным программам не предлагаются; на них наложено своего рода табу. А вот чтобы посчитать эти объёмы, нам уже не обойтись без средств оценки производительности. Далеко ходить не нужно, для этих целей отлично подойдёт Системный монитор Windows. Чтобы начать работу:

• запускаем подозрительный процесс и оставляем его фоном
• в строке поиска вводим быструю команду Windows

perfmon

• выбираем слева Системный монитор и удаляем автоматические счётчики, щёлкнув по красному крестику

• в освобождённом квадранте правой мышкой выбираем Добавить счётчики…

Если я подозреваю, например, процесс chrome.exe в причине утечки, мне нужно его найти и выделить среди остальных. Выбираю счётчик Процесса…

а затем подсчёт Байт исключительного пользования. Нам осталось подобрать само имя процесса. Если вы хотите выбрать несколько, зажимайте Shift: при выборе. Заканчиваем кнопкой Добавить>> и смотрим:

Сразу рекомендую в Свойствах счётчиков выставить время перехвата от 600 сек (если есть время, можно и гораздо больше).

Сейчас появятся данные по нагрузке на оперативную память со стороны выбранной программы. Моментального результата не будет: иногда приходится ждать часами, пока опасения не подтвердятся. А “подтвердятся” выглядят примерно так:

Скачкообразное увеличение потребления свидетельствует о проблеме в связанных с процессом файлах. Проблема такого способа одна – такой картинки возможно “придётся” ждать часами, а то и днями. И это в течение единовременного сеанса. Сейчас себе такое может позволить далеко не всякий администратор. Так что этот способ (вполне себе официально документируемый) хорош либо для приложений с явными дефектами, которые сразу вешают систему в течение короткого времени, либо для “посмотреть наглядно, как оно работает”. Иногда помогает добавление ещё одного счётчика – Байт виртуальной памяти . Это показатель текущего размера виртуального адресного пространств, которое используется нашим приложением. Так вот, сравнение показаний может привести к таким выводам:

• утечка оперативной памяти выражается в постоянном увеличении числа байт исключительного пользования именно в файлах данных
• утечки по остальным приложениям и программам – это разрастание виртуального пространства.

Однако процесс поиска можно под-ускорить или под-уточнить. Попробуйте добавить ещё несколько счётчиков. Проверьте, что подозрительные процессы запущены. А среди новых счётчиков найдите:

• Память->Байт в выгружаемом страничном пуле
• Память->Байт в невыгружаемом страничном пуле
• Файл подкачки-> % использования

В свойствах счётчиков выставляем длительность 600 сек., форма вывода – Отчёт:

Попейте чайку, пока счётчики не разгонятся. Через указанное время можно сделать предварительные выводы. А они заключаются в следующем:

• утечки пользовательского режима выглядят как непрерывно увеличивающиеся показатели миллионов байт по строке Байт в выгружаемом страничном пуле. Это влечёт и увеличение в строке % использования Файла подкачки;
• утечки в режиме ядра проявляются в строке Байт в невыгружаемом страничном пуле. Хотя и второй показатель Памяти тоже может “страдать”. Однако. Учитывая то, что приложения время от времени память кэшируют, величины могут изменяться в незначительном диапазоне (туда-сюда). Это нормально. Но если кривая ползёт неуклонно вверх, у вас налицо утечка оперативной памяти.

В одну статью диагностику и решение мне запихнуть не удалось. Так что в следующей статье рассмотрим варианты как попытаться победить утечку в зависимости от источника проблемы: ядро или пользователь?

Успехов.