DA0018. 32-битное приложение выполняется с ограничениями управляемой памяти процесса

Идентификатор правила	DA0018
Категория	Использование средств профилирования
Метод профилирования	Выборка
Сообщение	Объем выделяемой управляемой памяти близок к заданному по умолчанию пределу для 32-разрядных процессов.Возможно, в приложении ограничено использование памяти.
Тип правила	Предупреждение

При профилировании методом выборки, памяти .NET или конфликтов ресурсов необходимо собрать не меньше 10 экземпляров, чтобы вызвать срабатывание правила.

Причина

Системные данные, собранные во время сеанса профилирования свидетельствуют о том, что кучи памяти .NET Framework близки к максимальному для управляемых куч размеру в 32-разрядном процессе.Максимальный размер – это значение по умолчанию.Он определяется на основе общего размера адресного пространства процесса, которое можно выделить под байты исключительного пользования.В отчете указывается максимальное значение для куч, полученное во время активности профилируемого процесса.Рассмотрим профилирование еще раз, воспользовавшись методом профилирования памяти .NET и оптимизировав использование приложением управляемых ресурсов.

Если размер управляемых куч близок к заданному по умолчанию предельному значению, возможно, автоматический процесс сборки мусора будет инициироваться чаще.Это приведет к увеличению дополнительных затрат на управление памятью.

Это правило применяется только для 32-разрядных приложений, выполняющихся на 32-разрядных компьютерах.

Описание правила

Среда CLR Microsoft .NET обеспечивает автоматический механизм управления памятью, который использует сборщик мусора для удаления из памяти объектов, более не используемых приложением.Работа сборщика мусора основана на понятии поколений и предположении о краткосрочном характере выделения памяти.Например, время существования локальных переменных должно быть небольшим.Поколение новых объектов начинается с 0 (поколение 0), затем они переходят в поколение 1, если они сохраняются после сборки мусора, и, наконец, в поколение 2, если они все еще используются приложением.

Управляемые объекты, размер которых превышает 85 Кб, размещаются в куче для массивных объектов, в которой сборка мусора и сжатие выполняется реже, чем для объектов меньшего размера.Управление массивными объектами выполняется отдельно, поскольку предполагается, что они более постоянные, а также потому, что смешивание постоянных массивных объектов с часто размещаемыми маленькими объектами может привести к очень сильной фрагментации кучи.

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

Анализ предупреждения

Дважды щелкните сообщение в окне со списком ошибок, чтобы перейти в представление Метки.Найдите столбцы Память CLR .NET\Байт во всех кучах и Всего фиксировано байт.Установите, есть ли какие-либо этапы выполнения программы, на которых выделение управляемой памяти происходит активнее, чем на других этапах.Сравните значения в столбце Байт во всех кучах с показателем сборки мусора, указанным в столбцах Память CLR .NET\Сборок мусора для поколения 0, Память CLR .NET\Сборок мусора для поколения 1 и Память CLR .NET\Сборок мусора для поколения 2, чтобы определить, влияет ли структура управляемого выделения памяти на интенсивность сборки мусора.

В приложении .NET Framework среда CLR ограничивает общий размер управляемых куч величиной чуть меньше половины от максимального размера участка адресного пространства процесса, соответствующего области исключительного пользования.Для 32-разрядных процессов, выполняющихся на 32-разрядных компьютерах, верхний предел участка исключительного пользования адресного пространства процесса составляет 2 Гб.Поскольку общий размер управляемых куч начинает приближаться к заданному по умолчанию предельному значению, дополнительные затраты на управление памятью могут возрасти, а производительность приложения – снизиться.

Если чрезмерное использование управляемой памяти создает проблему, можно прибегнуть к одном из следующих методов:

• оптимизация использования ресурсов управляемой памяти приложением

  -или-

• принятие мер по сокращению архитектурных ограничений на максимальный размер виртуальной памяти для 32-разрядного процесса.

Чтобы оптимизировать использование ресурсов управляемой памяти приложением, соберите данные о выделении управляемой памяти во время сеанса профилирования выделения памяти .NET.Ознакомьтесь с отчетами Представления данных в памяти в средствах профилирования .NET, чтобы разобраться со структурой выделения памяти в приложении.

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

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

Дополнительные сведения о повышении производительности сборки мусора см. в технической статье по .NET Framework на веб-сайте MSDN: Garbage Collector Basics and Performance Hints.

Чтобы ослабить архитектурные ограничения виртуальной памяти для размера участка исключительного пользования в адресном пространстве процесса, попытайтесь запустить этот 32-разрядный процесс на 64-разрядном компьютере.32-разрядный процесс на 64-разрядном компьютере может получить до 4 Гб виртуальной памяти исключительного пользования.

64-разрядный процесс, выполняющийся на 64-разрядном компьютере, может получить до 8 Тб виртуальной памяти.Рекомендуется выполнить повторную компиляцию приложения, чтобы оно изначально выполнялось как 64-разрядное приложение.Это правило используется исключительно в информационных целях и не обязательно требует выполнения корректирующих действий.