Поделиться через

Сборка мусора рабочей станции и сервера

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

  • Сборка мусора рабочего места (GC), предназначенная для клиентских приложений. Это вариант GC по умолчанию для автономных приложений. Например, для размещенных приложений на платформе ASP.NET хост определяет версию сборщика мусора по умолчанию.

    Сборка мусора рабочей станции может быть параллельной или не одновременной. Параллельная ( или фоновая) сборка мусора позволяет управляемым потокам продолжать операции во время сборки мусора. Фоновая сборка мусора заменяет параллельную сборку мусора в .NET Framework 4 и более поздних версиях.

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

    • В .NET Core сборка мусора сервера может быть не одновременной или фоновой.

    • В .NET Framework 4.5 и более поздних версиях сборка мусора сервера может быть не одновременной или фоновой. В .NET Framework 4 и предыдущих версиях сборка мусора сервера не является параллельной.

На следующем рисунке показаны выделенные потоки, которые выполняют сборку мусора на сервере:

Потоки сборки мусора сервера

Вопросы, связанные с производительностью

Рабочая станция GC

Ниже приведены рекомендации по потоковой работе и производительности сборки мусора рабочей станции:

  • Коллекция происходит в потоке пользователя, который инициировал сборку мусора, и остается на том же уровне приоритета. Так как потоки пользователей обычно работают с обычным приоритетом, сборщик мусора (который работает в потоке с обычным приоритетом) должен конкурировать с другими потоками за время ЦП. (Потоки, выполняющие родной код, не приостанавливаются ни при сборке мусора сервера, ни при сборке мусора рабочей станции.)

  • Сборка мусора рабочей станции всегда используется на компьютере с одним логическим ЦП независимо от параметра конфигурации.

Серверная сборка данных

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

  • Сбор данных осуществляется в нескольких выделенных потоках. В операционной системе Windows эти потоки выполняются на THREAD_PRIORITY_HIGHEST уровне приоритета.

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

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

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

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

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

См. также