Как найти анализ памяти

Проблемы с оперативной памятью сказываются на работоспособности операционной системы в целом. Даже после установки нескольких планок оперативной памяти, особенно разных производителей, рекомендуется выполнить диагностику проблем памяти компьютера. Проверку оперативной памяти можно выполнить используя сторонние приложения или встроенные средства операционной системы Windows 10.

Данная статья расскажет как правильно проверить оперативную память на ошибки в Windows 10. После появления такого рода проблем, пользователи встречаются с так званными экранами смерти. Притом на каждом с экранов может выводиться другой код остановки, который можно предоставить в службу поддержки пользователей Windows 10.

Диагностика проблем памяти Windows 10

Средство проверки памяти Windows

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

1. В поисковой строке начните вводить Средство проверки памяти Windows, и в результатах поиска нажмите Запуск от имени администратора.
2. Теперь в открывшемся окне средства проверки оперативной памяти нажмите Выполнить перезагрузку и проверку (рекомендуется).

После перезагрузки компьютера начнется процесс проверки оперативной памяти на ошибки. В пользователя есть возможность изменить параметры проверки: тип проверки, использование кэша и количество проходов теста. По завершению проверки памяти компьютера он будет перезагружен в интерфейс операционной системы.

В центре уведомлений будет указано результат тестирования. Если же ошибки памяти не обнаружены, но все же в случае появления синих экранов по непонятной для пользователя причине, можете воспользоваться другими средствами проверки. Более подробные данные о результатах тестирования можно посмотреть в журнале событий Windows 10.

В разделе Журнал событий > Система найдите сведения о результатах проверки памяти от источника MemoryDiagnostics-Results. В результатах будет сообщено что память компьютера проверена с помощью проверки памяти Windows.

Тест оперативной памяти AIDA64

Классическое приложение AIDA64 позволяет не только посмотреть характеристики компьютера, но и выполнить обычное и стресс тестирование устройств. По завершению тестирования, пользователю будут выведены его результаты в случае удачи. Перед началом тестирования нужно обязательно запустить программу от имени администратора Windows 10.

Перейдите в раздел Сервис > Тест кэша и памяти. В открывшемся окошке для запуска тестирования нажмите кнопку Start Benchmark.

После завершения теста можно сохранить результаты тестирования. В процессе тестирования пользоваться компьютером не получиться, потому что все ресурсы будут направлены на тест.

Вместе с просмотром какая оперативная память установлена на компьютере средствами операционной системы дополнительно в пользователей есть возможность проверить оперативную память на ошибки в Windows 10. Несмотря на то что множество утилит сторонних разработчиков позволяют выполнить диагностику памяти, для тестирования оперативной памяти достаточно средств системы.

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

Если на компьютере под управлением Windows 10 стали часто возникать сбои, случайные перезагрузки, зависания, ошибки BSOD, а приложения стали работать очень медленно, то определить причину проблемы может быть довольно сложно — она может быть связана с программным обеспечением или аппаратной частью.

Тем не менее, оперативная память — это то, что нужно проверить в первую очередь. Дело в том, что неисправный модуль памяти может привести не только к неправильному функционированию компьютера, но и к повреждению пользовательских файлов.

Несмотря на то, что в Интернете доступные сторонние инструменты для диагностики памяти, Windows 10 включает собственное средство проверки памяти для выявления потенциальных проблем с ОЗУ.

В этом руководстве приведены шаги по использованию Средства проверки памяти Windows для обнаружения неисправного модуля памяти.

Как диагностировать проблемы с памятью в Windows 10

• Откройте Панель управления (нажмите клавишу Windows и введите “панель управления”, затем выберите соответствующий вариант в результатах поиска).
• Выберите “Просмотр: Категория”, затем перейдите в раздел Система и безопасность.
• Выберите секцию Администрирование.
• Дважды щелкните по иконке Средство проверки памяти Windows.

Совет: в качестве альтернативы можете использовать сочетание клавиш Windows + R , затем введите mdsched.exe и нажмите OK для запуска инструмента.

• Выберите вариант Выполнить перезагрузку и проверку (рекомендуется). Инструмент также предлагает альтернативную опцию — выполнить проверку при следующем включении компьютера.
• После перезагрузки компьютера запуститься среда “Средство диагностики памяти Windows”, и тестирование будет проведено в режиме “Обычный”. В данном режиме инструмент проводит все проверки режима “Базовый”, а также тесты LRAND, Stride6 (с включенным кэшем), CHCKR3, WMATS+ и WINVC.

Вы можете использовать режим “Обычный” для тестирования памяти компьютера, а можете нажать клавишу F1 в любое время, чтобы открыть страницу “Параметры” для изменения настроек сканера.

На странице “Параметры” вы можете выбрать режим “Базовый”, который включает только тесты MATS+, INVC и SCHCKR (с включенным кэшем).

Также можно выбрать режим “Широкий”, который включает все доступные тесты режима “Обычный”, а также MATS+ (с отключенным кэшем), Stride38, WSCHCKR, WStride-6, CHCKR4, WCHCKR3, ERAND, Stride6 (с отключенным кэшем) и CHCKR8.

При необходимости вы можете перемещаться по различным параметрам с помощью клавиши TAB для изменения настроек кэша. Если вы отключите кэш, инструмент будет обращаться напрямую к данным в ОЗУ, что обеспечивает полноту теста. Кроме того, вы можете также установить число проходов сканера.

После того, как вы закончите выбирать свои параметры, просто нажмите клавишу F10, чтобы вернуться на главную страницу, и сканирование запустится автоматически.

Анализ результатов сканирования

• Откройте меню “Пуск”, выполните поиск eventvwr.exe и нажмите клавишу Enter, чтобы открыть приложение “Просмотр событий”.
• Раскройте пункт “Журналы Windows”.
• Щелкните правой кнопкой мыши по пункту “Система” и выберите опцию “Найти”.
• Введите MemoryDiagnostics-Results и нажмите кнопку “Найти далее”.

• Закройте диалоговое окно “Найти”.
• В окне приложения “Просмотр событий” дважды кликните по записи MemoryDiagnostics-Results и посмотрите сообщение. Если в описании указано “Память компьютера проверена с помощью средства проверки памяти Windows; ошибок не обнаружено”, значит можно исключить проблемы с оперативной памятью в качестве причины неполадок.

Если результат показывает одну или несколько ошибок, вы можете попробовать запустить тест памяти “Широкий” и перепроверить результаты. Если вы по-прежнему видите хотя бы одну ошибку на одном из модулей ОЗУ, вероятно планку памяти придется заменить.

Иногда, когда тест завершается сбоем, инструмент может указать, какой из модулей имеет проблему с результатами. Однако, если он не может предоставить эту информацию, вам может потребоваться вручную отключить и протестировать каждый модуль памяти, пока не выясните, какой модуль неисправен.

Хотя это руководство предназначено для пользователей Windows 10, средство проверки памяти Windows доступно для использования также в Windows 8.1 и Windows 7.

В случае, если ваш компьютер или ноутбук под управлением Windows 10 стал работать ощутимо медленнее, стали возникать сбои, случайные перезагрузки, ошибки BSOD (синий экран смерти), то возможно все эти проблемы связаны с неполадками в оперативной памяти.

Далее рассмотрим, как проверить оперативную память на ошибки, используя для выявления возможных проблем с ОЗУ штатные средства операционной системы Windows 10.

Как проверить оперативную память на ошибки в Windows 10

Обратите внимание, что по умолчанию диагностическое сканирование осуществляется в режиме «Обычный» (его, как правило более чем достаточно для выявления практически всех возможных неполадок с оперативной памятью). При необходимости вы можете, используя клавишу F1, выбрать другой режим проведения диагностики памяти (Базовый или Широкий), которые отличаются набором тестов.

Результаты проверки

На этом всё. Если в результате проверки будет выявлена одна или несколько ошибок, то попробуйте снова выполнить тест памяти в режиме «Широкий». Если ошибки (а) появляются и после повторного тестирования, то с большой долей вероятности неисправный модуль оперативной памяти придётся заменить.

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

В операционной системе Windows 11 место на диске могут занимать следующие данные:

• Временные файлы и другой цифровой мусор (остатки после удаления программ, игр, папки Temp и прочее).
• Неиспользуемые профили пользователей ПК, ранее использовавшиеся в системе.
• Кеш браузеров и мессенджеров.
• Установленные игры и приложения.
• Фото, видео, музыка, документы и различные пользовательские данные.
• Файлы восстановления системы.
• Файлы предыдущих систем (пака Windows.old).
• Обновления Windows 11.
• Бэкапы системы.

И другие файлы.

Нехватка места на диске может подорвать стабильную работу  операционной системы Wibdows 11 — вызвав торможение, медленную работу ПК, неработоспособность различных приложений и другие проблемы.

В ОС Windows 11 имеются средства за контролем памяти. Для получения сведений переходим выполняем следующие действия:

1. Нажимаем на клавиатуре горячие клавиши «Win+I» для перехода в Параметры Windows 11.
2. В окне «Параметры» переходим в раздел «Система» в меню справа.
3. Находим вкладку «Память» и переходим в нее.

В окне «Память» находится две вкладки:

1. Приложения и компоненты.
2. Временные файлы.

На каждой вкладке имеется шкала, по которой можно понять, что занимает место на диске.

Анализируя эти данные можно выполнить очистку диска, а если данных недостаточно, всегда можно воспользоваться сторонним ПО.

Анализ дискового пространства при помощи встроенной утилиты «Diskusage»

Для просмотра всех параметров утилиты используем команду в командной строке:

diskusage /?

Пример 1. Показать 10 самых больших папок на диске «С:»:

diskusage C: /TopDirectory=10 /humanReadable /skipReparse

Пример 2: Показать 10 самых больших файлов на диске «С:» с датой их создания:

diskusage C: /TopFile=10 /displayFlag=0x080 /humanReadable /skipReparse

Данная утилита отлично подойдет для анализа занятости места на диске при удаленной диагностике.

Приложение «WinDirStat»

Ссылка на скачивание.

WinDirStat (Windows Directory Statistics) — бесплатная программа для просмотра и очистки мусора из системы ОС Windows. При запуске программа сканирует систему и отображает данные в виде дерева каталогов.

Возможности программы WinDirStat:

• Отображение в виде списка каталогов, напоминающее древовидное представление проводника Windows с сортировкой по размеру файла/папки.
• Древовидная карта, отображающая содержимое каталогов.
• Отображение списка расширений файлов.

Приложение «WizTree»

Ссылка на скачивание.

С помощью WizTree можно очень легко найти и удалить ненужные файлы с жесткого диска. Визуальная древовидная карта отображает размеры всех файлов в системе, помогая быстро находить большие файлы и папки.

Доступна 32 и 64 битная версия, а также Portable версия программы.

Приложение «TreeSize Free»

Ссылка на скачивание.

TreeSize Free покажет, чем занята емкость диска. Отображение в виде проводника Windows с различными фильтрами. Программа очень проста в использовании.

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

Получить общие представления о распределении оперативной памяти можно с помощью Диспетчера задач. Здесь на вкладке «Процессы» в колонке «Память» можно видеть, сколько памяти в килобайтах такие-то процессы используют в данный момент времени. Аналогичные сведения в столбце «Память (Частный рабочий набор)» отображаются на вкладке «Подробно». При необходимости вы можете отсортировать процессы по объему потребляемых ими ресурсов, кликнув по заголовку столбца. Как видно из приложенного ниже скриншота, главным потребителем ОЗУ в нашем примере является процесс браузера Google Chrome.

Примечание: выбрав в контекстном меню процесса опцию «Перейти к службам», можно увидеть службы, в этот процесс загруженные. 

Общие сведения о распределении памяти доступны на вкладке «Производительность» в подразделе «Память». Особенный интерес представляет собой блок данных структуры памяти, его значения стоят того, чтобы рассмотреть их чуть более подробно.

• Используется —RAM, используемая в настоящее время. 

• Доступно — объем памяти, доступной для использования Windows, драйверами, процессами и драйверами.

• Выделено значение, представленное двумя числами — суммой оперативной памяти и памяти файла подкачки.

• Кэшировано — объем памяти, выделяемый под хранение данных, которые могут понадобиться в будущем. На графике «Структура памяти» кэшированная память обозначается как «Зарезервировано».

• Выгружаемый и не выгружаемый пулы — ресурсы RAM, используемые исключительно ядром Windows. выгружаемый пул отличается от невыгружаемого тем, что первый может быть записан в файл подкачки.

Немногим больше сведений об использовании памяти конкретными процессами может дать оснастка «Монитор ресурсов», открыть которую можно из вкладки «Производительность» Диспетчера задач или командой resmon в окошке «Выполнить». Помимо цветного графика распределения памяти, в целом дублирующего блок структуры памяти в Диспетчере задач, Монитор ресурсов на вкладке «Память» отображает список запущенных процессов с изменяющимися в режиме реального времени значениями. Рассмотрим вкратце относящиеся к расходу ОЗУ.

• Завершено — в колонке отображается максимальный объем файла подкачки, который был использован процессом за все время открытой им сессии. 

• Рабочий набор — объем ОЗУ, используемый процессом в настоящий момент времени. В этот объем включается также зарезервированная память.

• Общий набор — это объем памяти, который может быть забран у текущего процесса для некоего другого процесса, если последний в порядке приоритета станет нуждаться в ресурсах.

• Частный набор — это используемая процессом память, которая не может быть высвобождена и передана другим процессам. 

Если вы хотите анализировать распределение оперативной памяти на профессиональном уровне, вам понадобиться что-то более функциональное, чем Монитор ресурсов и Диспетчер задач. Например, утилита RAMMap, разработанную сотрудниками Microsoft Марком Руссиновичем и Брайсом Когсвеллом. Описать все ее возможности в рамках одной статьи средней длины не представляется возможным, впрочем, рядовому пользователю вполне будет достаточно знать лишь о некоторых аспектах работы с этим инструментом.

Наибольший интерес в RAMMap представляют вкладки «Use Counts», «Processes» и «File Details». Первая содержит цветной график, в котором каждый цвет соответствует определенному типу памяти. Рассмотрим некоторые наиболее интересные значения.

• Process Private — память, отведенная под исключительно отдельные процессы.

• Mapped File — область памяти системного файлового кэша.

• Shareble — используемая процессами память, которая может быть освобождена для других процессов.

• Paged Pool и Nonpaged Pool — ОЗУ, отведенная исключительно под процессы ядра. Первый ее тип может быть записан в дисковый кэш, второй не может.

• Session Private — часть памяти, используемая некоторыми системными драйверами.

• Metafile — память, отведенная под ту часть системного кэша, который хранит метаданные NTFS и MFT.

• Unused — свободная, неиспользуемая в данный момент RAM.

• Total — общий размер ОЗУ, доступный для использования в вашей системе.

Если содержимое вкладки «Use Counts» дает общее представление о типах используемых страниц памяти и отведенном под них объема ресурсов, то на вкладке «Processes» можно посмотреть, сколько памяти отводится под каждый конкретный процесс.

Наконец, вкладка «File Details» отображает список файлов, отнесенных системой в память. Это могут быть не только исполняемые файлы, но и всякие другие файлы, используемые программами и операционной системой. Столбец «Size» на вкладке показывает не объем ОЗУ, а физический размер файла на жестком диске.

В отличие от Диспетчера задач и Монитора ресурсов, RAMMap не позволяет управлять процессами, она служит для получения подробных сведений о распределении ресурсов памяти, впрочем, кое-что утилита всё же умеет. Так, если вы перейдете в меню «Empty», то найдете в нём несколько опций очистки страниц оперативной памяти, зарезервированной, но неиспользуемой в данный момент запущенными процессами.

Время на прочтение
5 мин

Количество просмотров 3.7K

Меня зовут Андрей, я нефункциональный тестировщик в компании «Тензор». Наш отдел занимается тестированием клиентской производительности веб-приложений Saby. В частности, одно из направлений — тестирование продукта на утечки памяти. Так как у нас большинство приложений Single Page Application, то утечки памяти могут сильно мешать нашим пользователям. Другим уязвимым участком системы является сервер построения HTML (который готовит html-страничку перед отправкой ее клиенту). Он так же, как и SPA-приложение, достаточно долго работает без перезагрузки и поэтому даже небольшая постоянная утечка может превратиться в большое потребление памяти. Перед отправкой в продакшн мы запускаем автотесты на наличие утечек памяти. В процессе правки найденных утечек мы поняли, что часто разработчики больше времени тратят на локализацию утечки памяти, чем на ее правку.

Почему уходит много времени на локализацию утечки памяти

В сети есть много статей о том, ĸаĸ правильно искать утечки и анализировать полученные дампы памяти. Однако примеры в них сильно упрощены, да и изначально знаешь, в чем утечка и куда смотреть. В реальности дампы памяти, кроме утечки, содержат много «нужных» объектов. Глядя на несколько десятков тысяч объектов одинакового типа, иногда и не знаешь, с чего начать разбор. Например, на рис. 1 ниже показана небольшая утечка при переходе в карточку контакта на сайте contacts.google.com. Утечка менее 100 Кбайт, но при этом создается уже более 10 тысяч объектов. Если сайт сложнее, то объектов может быть еще больше. Поэтому у нас появилась идея облегчить отладку утечек памяти, автоматизировав поиск объектов, которые являются утечкой.

На рис. 2 представлена схема нашего классического теста на утечки памяти. Тестируемым действием может быть как действие пользователя в браузере, так и выполнение какого-либо кода на стороне сервера (Node.js). После 4 повторов тестируемого действия мы получаем 4 дампа памяти (HeapSnapshot, или просто снапшот), которые необходимо проанализировать.

Как мы ищем в дампах памяти объекты, которые утекли

У таких объектов есть несколько характерных признаков:

1. Это должны быть объекты одинакового типа (Object, Array, (string) и т.д).

2. Они должны утекать при каждом повторе действия. Если в одном из повторов нет такого объекта, его уже нельзя назвать утечкой в обычном понимании.

3. У этих объектов должны быть родители одинаковых типов (то есть цепочка Retainers должна быть схожа по виду). Все потому, что утечка происходит из одного и того же места в коде, а значит, контекст возникновения объектов должен быть один и тот же или схожим по виду.

Разберем наглядно. Наш код-пример (рис. 3) создает утечку: в Array при каждом повторе появляется новый Object с другим Object в одном из его параметров. Выделенный кусок кода повторяется 3 раза, после каждого снимается снапшот. И после снятия последнего приступаем к их анализу, выбрав режим Object allocated between snapshots (рис. 4).

Между 1 и 2 дампом, как и между 2 и 3, создается объект с типом Object. При этом цепочка Retainers у них похожа (Object — Array — system / Context — …), но идентификаторы некоторых объектов различаются.

Так как все признаки утекших объектов присутствуют, то начинать анализ стоило бы именно с выбранных объектов Object @175399 или @175441.

Алгоритм поиска утекших объектов

Итак, после нашего классического теста (рис. 2) у нас 4 снапшота. Что нам надо сделать, чтобы в них найти объекты утечки памяти: 

1. Распарсить снапшоты. Нам надо получить полностью дерево со связями. Раньше мы парсили json самописным сĸриптом, но потом наткнулись на парсер в исходниĸах Chromium и успешно его используем (ссылĸа). Дополнительно он очищает снапшот от различных системных объеĸтов, что упрощает анализ.

2. Отфильтровать объекты, которые удалил GC. Надо найти объеĸты, ĸоторые создались между соседними снапшотами и присутствуют в последнем снапшоте (значит, объеĸт не удален при очистĸах мусора). Исĸать объекты надо по id (в упомянутой либе это параметр object_id, а в devtools это цифры у объекта с @ в начале), они постоянны для одного объеĸта между разными снапшотами. В итоге мы получаем 3 группы объеĸтов: созданные между 1-2 снапшотами, между 2-3 и между 3-4 (на рис. 5 проиллюстрирована схема). 

   

3. Отфильтровать системные объекты и объекты с нулевым весом. Предложенный парсер сам убирает системные объекты на этапе парсинга. Объекты с нулевым весом могут присутствовать и в более поздних снапшотах, но это просто пустышĸи. Предполагаем, они нужны для усĸорения V8, но точнее этот вопрос не изучали. Тем не менее, они могут мешать в анализе, так как не являются утечкой памяти.

4. Найти всех родителей. Надо составить все пары «объеĸт — родитель». Используя парсер, сделать это проще простого: у объеĸта связи с его родителями хранятся в переменной edges_to, которые ведут к родительскому объекту.

5. Для каждой пары получить строковое представление их связи. Строковым представлением объекта будет его тип (параметр class_name) — нам надо соединить тип объекта и тип его родителя. Из примера на рис. 4 у объекта с id @175367 тип Object, а у его родителя (объекта с id @136513) — тип Array. Таĸим образом, получится пара Object — Array. Аналогично будет и у объектов @175409 — @136513. Это то, что мы видим в цепочĸе Retainers в DevTools при ручном анализе.

6. Поиск одинаковых пар «объект — родитель» между группами. Это третий признак утечки — у утекаемых объектов должна быть схожая цепочка родителей, так как у них схожий контекст. Если таĸие имеются, это подозрение на утечĸу. Ищем по совпадению строĸи, то есть в нашем примере ищем те же Object — Array в других группах, полученных после 3 шага (рис. 6).

   

   На этом этапе выводим в сборке (рис. 7) все найденные пары из первого снапшота с указанием id объектов, в также путь до последнего четвертого снапшота. Сделано так специально, потому что по этим объектам уже много раз прошелся сборщик мусора и у них остались только связи, которые являются утечкой памяти. 

   Далее передаем дело на ручной анализ — разработчику остается только открыть снапшот и проанализировать причину удержания этих объектов в памяти. Последующий анализ не отличается от других методиĸ анализа утечеĸ памяти в JS. 

   

Недостатки алгоритма, которые мы обнаружили

У представленного алгоритма есть несĸольĸо недостатĸов: 

1. Тест относительно долгий (занимает в среднем 5–10 минут). Самой медленной частью является снятие и получение снапшота. Если тестируемое действие у вас выполняется в разы быстрее, чем снятие снапшота, лучше тестировать на утечки в 2 прогона:

• в первом — без снятия снапшота смотреть утечку только по размеру кучи;

• во втором — если первый прогон показал утечку, запускать углубленный анализ со снятием снапшотов.

1. У алгоритма иногда бывают ложные срабатывания. Чем больше количество снапшотов, тем меньше этих срабатываний, но тем дольше идет тест. Оптимально для нас было выбрано 4 снапшота (не более 5% ложных срабатываний от общего количества тестов). Редкие ложные срабатывания убираются перезапуском теста. Причина заключается в том, что при меньшем количестве снапшотов выше вероятность получить схожие пары «объект — родитель» в каждом снапшоте, которые при этом не будут утечкой. Также не успевают удалиться некоторые объекты, которые не являются мусором, но сидят в памяти для ускорения V8 и удалятся позднее.

Какой профит мы получили от использования описанного алгоритма

1. Сильно облегчили анализ ошибок утечек памяти для разработчиков. Ранее почти для каждой ошибки разработчику приходилось вспоминать азы анализа дампов памяти, затем разворачивать локальную версию продукта, воспроизводить баг. Все это могло занять несколько дней. Теперь в большинстве случаев мы сразу можем указать разработчику, какой объект в каком модуле остается в памяти. Ему остается разобраться в причинах удержания этого объекта. Довольно часто причины тривиальны, и правка много времени не занимает.

2. Можем точнее определить, есть ли утечка. Очень часто Chrome создает системные объекты и держит их в памяти. При анализе только по размеру кучи это может вносить большую погрешность. По внедренному алгоритму мы отсеиваем такие объекты и можем понять, есть ли утечка из несистемных объектов.