Я пытаюсь использовать утилиту perfmon для отладки утечек памяти в процессе.
Вот как perfmon объясняет термины:
Рабочий набор - это текущий размер в байтах рабочего набора этого процесса. Рабочий набор - это набор страниц памяти, недавно затронутых потоками в процессе. Если объем свободной памяти в компьютере превышает пороговое значение, страницы остаются в рабочем наборе процесса, даже если они не используются. Когда объем свободной памяти падает ниже порогового значения, страницы обрезаются из рабочих наборов. Если они необходимы, они затем будут мягко сбиты обратно в рабочий набор перед тем, как покинуть основную память.
Виртуальные байты - это текущий размер в байтах виртуального адресного пространства, которое использует процесс. Использование виртуального адресного пространства не обязательно подразумевает соответствующее использование страниц диска или основной памяти. Виртуальное пространство конечно, и процесс может ограничивать его способность загружать библиотеки.
Частные байты - это текущий объем памяти в байтах, выделенный этим процессом, который нельзя использовать совместно с другими процессами.
Вот вопросы, которые у меня есть:
Это частные байты, которые я должен измерить, чтобы быть уверенным в том, что у процесса есть какие-либо утечки, поскольку он не включает какие-либо общие библиотеки, и любые утечки, если они произойдут, будут происходить из самого процесса?
Какова общая память, используемая процессом? Это виртуальные байты или сумма виртуальных байтов и рабочего набора?
Есть ли какая-либо связь между частными байтами, рабочим набором и виртуальными байтами?
Есть ли другие инструменты, которые дают лучшее представление об использовании памяти?
Ответы:
Краткий ответ на этот вопрос заключается в том, что ни одно из этих значений не является надежным индикатором того, сколько памяти фактически использует исполняемый файл, и ни одно из них не подходит для устранения утечки памяти.
Частные байты относятся к объему памяти, запрошенному исполняемым файлом процесса - не обязательно к объему, который он фактически использует . Они являются «частными», потому что они (обычно) исключают файлы, отображаемые в памяти (то есть разделяемые библиотеки DLL). Но - вот в чем загвоздка - они не обязательно исключают память, выделенную этими файлами . Невозможно определить, произошло ли изменение в частных байтах из-за самого исполняемого файла или из-за связанной библиотеки. Частные байты также не являются исключительно физической памятью; они могут быть перенесены на диск или в список резервных страниц (т.е. больше не используются, но еще не выгружены).
Рабочий набор относится к общей физической памяти (ОЗУ), используемой процессом. Однако, в отличие от частных байтов, это также включает в себя отображенные в память файлы и различные другие ресурсы, поэтому это даже менее точное измерение, чем частные байты. Это то же значение, о котором сообщается в «Использование памяти» диспетчера задач, и в последние годы оно вызывает бесконечную путаницу. Память в рабочем наборе является «физической» в том смысле, что к ней можно обращаться без ошибок страницы; однако, список резервных страниц также все еще физически находится в памяти, но не отображается в рабочем наборе, и поэтому вы можете внезапно сбросить «Использование памяти» при сворачивании приложения.
Виртуальные байты - это общее виртуальное адресное пространство, занимаемое всем процессом. Это похоже на рабочий набор, в том смысле, что он включает в себя отображенные в память файлы (общие библиотеки DLL), но он также включает в себя данные в резервном списке и данные, которые уже были выгружены и находятся где-то в файле подкачки на диске. Общее количество виртуальных байтов, используемых каждым процессом в системе под большой нагрузкой, значительно увеличит объем памяти, чем машина имеет на самом деле.
Итак, отношения:
Здесь есть другая проблема; Точно так же, как разделяемые библиотеки могут выделять память внутри модуля приложения, что приводит к потенциальным ложным срабатываниям, сообщаемым в личных байтах вашего приложения , так и ваше приложение может в конечном итоге выделять память внутри общих модулей, что приводит к ложным отрицаниям . Это означает, что на самом деле ваше приложение может иметь утечку памяти, которая вообще никогда не проявляется в приватных байтах. Вряд ли, но возможно.
Частные байты являются разумным приближением к объему памяти, используемому вашим исполняемым файлом, и могут использоваться, чтобы помочь сузить список потенциальных кандидатов на утечку памяти; если вы видите, что число постоянно растет и бесконечно растет, вам следует проверить этот процесс на наличие утечек. Это, однако, не может доказать, что есть или нет утечка.
Одним из наиболее эффективных инструментов для обнаружения / исправления утечек памяти в Windows на самом деле является Visual Studio (ссылка ведет на страницу об использовании VS для утечек памяти, а не на страницу продукта). Rational Purify - это еще одна возможность. У Microsoft также есть более общий документ с рекомендациями по этому вопросу. В этом предыдущем вопросе перечислены другие инструменты .
Я надеюсь, что это проясняет некоторые вещи! Отслеживание утечек памяти - одна из самых сложных вещей при отладке. Удачи.
источник
Вы не должны пытаться использовать perfmon, диспетчер задач или любой подобный инструмент для определения утечек памяти. Они хороши для выявления тенденций, но не намного. Числа, которые они сообщают в абсолютном выражении, слишком расплывчаты и агрегированы, чтобы быть полезными для конкретной задачи, такой как обнаружение утечки памяти.
Предыдущий ответ на этот вопрос дал отличное объяснение того, что представляют собой различные типы.
Вы спрашиваете о рекомендации инструмента: я рекомендую Memory Validator. Возможность мониторинга приложений, которые выделяют миллиарды памяти.
http://www.softwareverify.com/cpp/memory/index.html
Отказ от ответственности: я разработал Memory Validator.
источник
Определение счетчиков perfmon было нарушено с самого начала и по некоторым причинам кажется слишком сложным для исправления.
Хороший обзор управления памятью Windows доступен в видеоролике « Раскрытые тайны управления памятью » на MSDN: он охватывает больше тем, чем необходимо для отслеживания утечек памяти (например, управление рабочим набором), но дает достаточно деталей в соответствующих темах.
Чтобы дать вам подсказку о проблеме с описаниями счетчика perfmon, вот внутренняя история о частных байтах из « Счетчика производительности частных байтов - Осторожно! » На MSDN:
Из « Планирования производительности » на MSDN:
источник
Здесь есть интересная дискуссия: http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/307d658a-f677-40f2-bdef-e6352b0bfe9e/ Я понимаю, что освобождение небольших ресурсов не отражается в частных байтах или рабочем наборе.
Короче говоря:
если я позвоню
тогда частные байты отражают только распределение, а не освобождение.
если я позвоню
тогда частные байты правильно отражают распределение и освобождение.
источник