Сборка мусора и производительность

Статья
04/11/2023

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

Средства анализа производительности

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

Счетчики производительности памяти

Счетчики производительности можно использовать для сбора данных производительности. Инструкции см. в разделе Профилирование среды выполнения. Категория счетчиков производительности "Память CLR .NET" (как описано в разделе Счетчики производительности в .NET) предоставляет сведения о сборщике мусора.

Отладка с помощью расширения SOS

Для проверки объектов в управляемой куче можно использовать отладчик Windows (WinDbg).

Чтобы установить WinDbg, установите средства отладки для Windows со страницы скачивания средств отладки для Windows.

События сборки мусора (трассировка событий Windows)

Трассировка событий Windows (ETW) — это система трассировки, дополняющая поддержку профилирования и отладки в .NET. Начиная с .NET Framework 4, события ETW для сборки мусора собирают полезные сведения для анализа управляемой кучи с точки зрения статистики. Например, событие GCStart_V1, которое вызывается перед началом сборки мусора, предоставляет следующие сведения:

собираемое поколение объектов;
что активировало сборку мусора;
тип сборки мусора (параллельная или непараллельная).

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

API профилирования

Интерфейсы профилирования среды выполнения (CLR) предоставляют подробные сведения об объектах, которые были затронуты во время сборки мусора. Профилировщик может получать уведомления о начале и завершении сборки мусора. Он может предоставлять отчеты об объектах в управляемой куче, включая идентификацию объектов в каждом поколении. Дополнительные сведения см. в разделе Общие сведения о профилировании.

Профилировщики могут предоставлять исчерпывающую информацию. Однако сложные профилировщики потенциально могут менять поведение приложения.

Отслеживание ресурсов домена приложения

Начиная с .NET Framework 4, функция отслеживания ресурсов домена приложения (ARM) позволяет узлам отслеживать загрузку ЦП и использование памяти доменом приложения. Дополнительные сведения см. в разделе Отслеживание ресурсов домена приложения.

Устранение проблем с производительностью

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

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

Проблема: создается исключение нехватки памяти

Существует два допустимых случая создания управляемого исключения OutOfMemoryException:

нехватка виртуальной памяти;

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

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

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

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

Проблема: процесс использует слишком много памяти

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

Если выяснилось, что проблема вызвана управляемой кучей, необходимо провести для управляемой кучи измерения в динамике, чтобы определить наличие каких-либо шаблонов.

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

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

Проверки производительности

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

Проблема: сборщик мусора недостаточно быстро освобождает объекты

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

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

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

Проблема: управляемая куча слишком сильно фрагментирована

Уровень фрагментации рассчитывается как отношение свободного пространства ко всей выделенной памяти для поколения. Для поколения 2 допустимый уровень фрагментации составляет не более 20 %. Поскольку поколение 2 может очень сильно вырасти, показатель фрагментации более важен, чем абсолютное значение.

Наличие большого объема свободного пространства в поколении 0 не является проблемой, так как это поколение, в котором выделяются новые объекты.

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

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

Чрезмерное закрепление объектов может привести к увеличению фрагментации. Если наблюдается высокая фрагментация, возможно, закреплено слишком много объектов.

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

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

При размещении среды CLR приложение может запросить сохранение сегментов сборщиком мусора. Это снижает частоту выделения сегментов. Для этого необходимо использовать флаг STARTUP_HOARD_GC_VM в перечислении STARTUP_FLAGS.

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

Если вы считаете, что нет допустимых причин для фрагментации, обратитесь в службу технической поддержки Майкрософт.

Проблема: слишком большие интервалы между сборками мусора

Сборка мусора выполняется в режиме мягкого реального времени, поэтому приложение должно быть способно допускать определенные перерывы. Критерием мягкого реального времени является своевременное завершение 95 % операций.

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

Эфемерные сборки мусора (поколения 0 и 1) длятся лишь несколько миллисекунд, поэтому уменьшение перерывов обычно нецелесообразно. Тем не менее, перерывы в сборках поколения 2 можно сократить, изменив шаблон обработки запросов приложения на выделение памяти.

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

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

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

Проблема: слишком большой размер поколения 0

Поколение 0 скорее всего имеет большое количество объектов в 64-разрядной системе, особенно если используется сборка мусора на сервере вместо сборки мусора на рабочей станции. Это происходит потому, что пороговое значение запуска сборки мусора для поколения 0 в таких средах выше и объемы сборки поколения 0 могут значительно увеличиваться. Производительность повышается, если приложение выделяет больше памяти перед активацией сборки мусора.

Проблема: слишком высокая загрузка ЦП во время сборки мусора

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

Частоту выделения можно отслеживать с помощью счетчика производительности Allocated Bytes/second. Дополнительные сведения см. в статье Счетчики производительности в .NET.

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

Проверки производительности
Определите, вызвана ли высокая загрузка ЦП сборкой мусора. Задайте точку останова в конце сборки мусора.

Процедуры проверка производительности

В этом разделе описаны следующие процедуры по выявлению причин проблем с производительностью.

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

Чтобы определить, вызвана ли проблема сборкой мусора, выполните следующие действия.

Проверьте следующие два счетчика производительности памяти:
- % времени в сборке мусора. Отображение времени, потраченного на выполнение сборки мусора с момента последнего цикла сборки мусора (в процентах). Этот счетчик используется, чтобы определить, тратит ли сборщик мусора слишком много времени на освобождение пространства в управляемой куче. Если время, затраченное на сборку мусора, сравнительно мало, это может указывать на проблему ресурсов за пределами управляемой кучи. Этот счетчик может предоставлять неточные данные при участии параллельной или фоновой сборки мусора.
- Всего зафиксировано байт. Отображение объема виртуальной памяти, в данный момент выделенной сборщиком мусора. С помощью этого счетчика можно определить, является ли память, используемая сборщиком мусора, избыточной частью памяти, которую использует приложение.
Большинство счетчиков памяти обновляются в конце каждой сборки мусора. Таким образом, они могут не отражать текущие условия, сведения о которых вам требуются.

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

В отладчике WinDbg или Visual Studio с расширением отладчика SOS, загруженном, введите команду исключения печати (pe) :

!pe

Если исключение является управляемым, OutOfMemoryException отображается как тип исключения, как показано в следующем примере.
```
Exception object: 39594518
Exception type: System.OutOfMemoryException
Message: <none>
InnerException: <none>
StackTrace (generated):
```
Если выходные данные не указывают на исключение, необходимо определить, к какому потоку относится исключение нехватки памяти. Введите следующую команду в отладчике, чтобы отобразить все потоки со своими стеками вызовов:

~\*kb

Поток со стеком, для которого есть вызовы исключений, обозначается аргументом RaiseTheException. Это объект управляемого исключения.
```
28adfb44 7923918f 5b61f2b4 00000000 5b61f2b4 mscorwks!RaiseTheException+0xa0
```
Чтобы создать дамп вложенных исключений, можно использовать следующую команду.

!pe -nested

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

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

В WinDbg с загруженным расширением отладчика SOS введите следующую команду, чтобы получить самый большой бесплатный регион:

!address -summary

Самая крупная свободная область отображается, как показано в выходных данных команды ниже.
```
Largest free region: Base 54000000 - Size 0003A980
```
В этом примере размер самой крупной свободной области составляет приблизительно 24 000 КБ (3A980 в шестнадцатеричном формате). Эта область гораздо меньше, чем требуется сборщику мусора для сегмента.

–или–

Используйте команду vmstat:

!vmstat

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

TYPE        MINIMUM   MAXIMUM     AVERAGE   BLK COUNT   TOTAL
~~~~        ~~~~~~~   ~~~~~~~     ~~~~~~~   ~~~~~~~~~~  ~~~~
Free:
Small       8K        64K         46K       36          1,671K
Medium      80K       864K        349K      3           1,047K
Large       1,384K    1,278,848K  151,834K  12          1,822,015K
Summary     8K        1,278,848K  35,779K   51          1,824,735K

Чтобы определить, имеется ли достаточный объем физической памяти, выполните следующие действия.

Запустите диспетчер задач Windows.
На вкладке просмотрите Performance зафиксированное значение. (В Windows 7 посмотрите на Commit (KB)System group.)

Если он Total близок к Limit, вы работаете с низкой физической памятью.

Чтобы определить объем памяти, зафиксированный управляемой кучей, выполните следующие действия.

Используйте счетчик производительности памяти # Total committed bytes, чтобы получить число байтов, фиксируемых управляемой кучей. Сборщик мусора выделяет фрагменты в сегменте по мере необходимости, но не все одновременно.

Примечание.

Не используйте счетчик производительности # Bytes in all Heaps, так как он не отражает фактическое использование памяти управляемой кучей. Размер поколения включается в это значение и, фактически, является его пороговым размером, то есть размером, который вызывает сборку мусора, если поколение заполнено объектами. Поэтому это значение обычно равно нулю.

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

Используйте счетчик производительности памяти # Total reserved bytes.

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

Внимание

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

В отладчике WinDbg или Visual Studio с загруженным расширением отладчика SOS введите следующую команду:

!eeheap -gc

Результат выглядит следующим образом.

Number of GC Heaps: 2
------------------------------
Heap 0 (002db550)
generation 0 starts at 0x02abe29c
generation 1 starts at 0x02abdd08
generation 2 starts at 0x02ab0038
ephemeral segment allocation context: none
  segment    begin allocated     size
02ab0000 02ab0038  02aceff4 0x0001efbc(126908)
Large object heap starts at 0x0aab0038
  segment    begin allocated     size
0aab0000 0aab0038  0aab2278 0x00002240(8768)
Heap Size   0x211fc(135676)
------------------------------
Heap 1 (002dc958)
generation 0 starts at 0x06ab1bd8
generation 1 starts at 0x06ab1bcc
generation 2 starts at 0x06ab0038
ephemeral segment allocation context: none
  segment    begin allocated     size
06ab0000 06ab0038  06ab3be4 0x00003bac(15276)
Large object heap starts at 0x0cab0038
  segment    begin allocated     size
0cab0000 0cab0038  0cab0048 0x00000010(16)
Heap Size    0x3bbc(15292)
------------------------------
GC Heap Size   0x24db8(150968)

Адреса с отметкой segment являются начальными адресами сегментов.

Чтобы определить большие объекты в поколении 2, выполните следующие действия.

В отладчике WinDbg или Visual Studio с загруженным расширением отладчика SOS введите следующую команду:

!dumpheap –stat

Если управляемая куча большая, dumpheap может занять некоторое время.

Вы можете начать анализ с последних нескольких строк вывода, поскольку в них перечислены объекты, занимающие наибольшее пространство. Например:
```
2c6108d4   173712     14591808 DevExpress.XtraGrid.Views.Grid.ViewInfo.GridCellInfo
00155f80      533     15216804      Free
7a747c78   791070     15821400 System.Collections.Specialized.ListDictionary+DictionaryNode
7a747bac   700930     19626040 System.Collections.Specialized.ListDictionary
2c64e36c    78644     20762016 DevExpress.XtraEditors.ViewInfo.TextEditViewInfo
79124228   121143     29064120 System.Object[]
035f0ee4    81626     35588936 Toolkit.TlkOrder
00fcae40     6193     44911636 WaveBasedStrategy.Tick_Snap[]
791242ec    40182     90664128 System.Collections.Hashtable+bucket[]
790fa3e0  3154024    137881448 System.String
Total 8454945 objects
```
Последний объект в списке является строкой и занимает больше всего места. Вы можете проанализировать приложение, чтобы понять, как можно оптимизировать строковые объекты. Чтобы просмотреть строки в диапазоне от 150 до 200 байт, введите следующее:

!dumpheap -type System.String -min 150 -max 200

Далее приведен пример результатов команды.
```
Address  MT           Size  Gen
1875d2c0 790fa3e0      152    2 System.String HighlightNullStyle_Blotter_PendingOrder-11_Blotter_PendingOrder-11
…
```
Использование целого числа вместо строки для идентификаторов может быть более эффективным. Если та же строка повторяется тысячи раз, рекомендуется настроить интернирование строк. Дополнительные сведения об интернировании строк см. в разделе справки по методу String.Intern.

Чтобы определить ссылки на объекты, выполните следующие действия.

В WinDbg с загруженным расширением отладчика SOS введите следующую команду, чтобы получить список ссылок на объекты:

!gcroot

–или–
Чтобы определить ссылки для конкретного объекта, включите соответствующий адрес:

!gcroot 1c37b2ac

Корни, найденные в стеках, могут быть ложными положительными результатами. Чтобы получить дополнительные сведения, используйте команду !help gcroot.
```
ebx:Root:19011c5c(System.Windows.Forms.Application+ThreadContext)->
19010b78(DemoApp.FormDemoApp)->
19011158(System.Windows.Forms.PropertyStore)->
… [omitted]
1c3745ec(System.Data.DataTable)->
1c3747a8(System.Data.DataColumnCollection)->
1c3747f8(System.Collections.Hashtable)->
1c376590(System.Collections.Hashtable+bucket[])->
1c376c98(System.Data.DataColumn)->
1c37b270(System.Data.Common.DoubleStorage)->
1c37b2ac(System.Double[])
Scan Thread 0 OSTHread 99c
Scan Thread 6 OSTHread 484
```
Команда gcroot может занять много времени. Любой объект, не освобождаемый сборщиком мусора, является активным объектом. Это означает, что некоторый корневой каталог напрямую или косвенно держится на объекте, поэтому gcroot должен возвращать сведения о пути к объекту. Необходимо изучить возвращенные диаграммы, чтобы понять, на какие объекты по-прежнему имеются ссылки.

Чтобы определить, выполнялся ли метод завершения, выполните следующие действия.

Запустите тестовую программу, содержащую следующий код:
```
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
```
Если с помощью теста удалось разрешить проблему, значит сборщик мусора не освобождает объекты, так как методы завершения для этих объектов приостановлены. Метод GC.WaitForPendingFinalizers позволяет методам завершения выполнить свои задачи и устраняет проблему.

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

В отладчике WinDbg или Visual Studio с загруженным расширением отладчика SOS введите следующую команду:

!finalizequeue

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

!threads -special

Эта команда предоставляет примерно следующие выходные данные.
```
   OSID     Special thread type
2    cd0    DbgHelper
3    c18    Finalizer
4    df0    GC SuspendEE
```
Поток метода завершения указывает, какой метод завершения (при наличии) выполняется в настоящее время. Если в потоке метода завершения не выполняются никакие методы завершения, значит он ожидает событие, которое запустит его выполнение. Как правило, поток находится в этом состоянии, так как выполняется с приоритетом THREAD_HIGHEST_PRIORITY и должен закончить выполнение методов завершения (при наличии) очень быстро.

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

В отладчике WinDbg или Visual Studio с загруженным расширением отладчика SOS введите следующую команду:

!dumpheap -type Free -stat

Эта команда выводит на экран общий размер всех свободных объектов в управляемой куче, как показано в следующем примере.
```
total 230 objects
Statistics:
      MT    Count    TotalSize Class Name
00152b18      230     40958584      Free
Total 230 objects
```

Чтобы определить свободное пространство в поколении 0, введите следующую команду для сведений о потреблении памяти по поколению: