Масштабируемость.NET 4 сборщика "мусора"
Я недавно сравнил.NET 4 сборщика "мусора", выделив интенсивно от нескольких потоков. Когда выделенные значения были зарегистрированы в массиве, я не наблюдал масштабируемости, как я ожидал (потому что система борется за синхронизируемый доступ к общему старому поколению). Однако, когда выделенные значения были сразу отброшены, я был испуган для наблюдения масштабируемости затем также!
Я ожидал, что временный случай масштабируется почти линейно, потому что каждый поток должен просто вытереть детский сад gen0, убирают и запускаются снова, не борясь ни за какие совместно используемые ресурсы (ничто выживающее старшим поколениям и неудачным обращениям в кэш № L2, потому что gen0 легко помещается в кэш L1).
Например, в этой статье MSDN говорится:
Выделения без синхронизаций В многопроцессорной системе, поколение 0 управляемой "кучи" разделяется на несколько арен памяти с помощью одной арены на поток. Это позволяет нескольким потокам делать выделения одновременно так, чтобы эксклюзивный доступ к "куче" не требовался.
Кто-либо может проверить мои результаты и/или объяснить это несоответствие между моими прогнозами и наблюдениями?
4 ответа
Не полный ответ на вопрос, но просто чтобы прояснить некоторые заблуждения: .NET GC работает одновременно только в режиме рабочей станции. В серверном режиме он использует параллельный сборщик мусора «остановить мир». Подробнее здесь . Отдельные питомники в .NET в первую очередь предназначены для избежания синхронизации при распределении; тем не менее они являются частью глобальной кучи и не могут быть собраны отдельно.
Рискну предположить, что происходит.
(1) Если у вас один поток и в поколении 0 свободно M места, то сборщик мусора будет запускаться только после того, как будет выделено M байтов.
(2) Если у вас N потоков и GC делит поколение 0 на N / M пространства для каждого потока, GC будет работать каждый раз, когда поток выделяет N / M байтов. Показательным моментом здесь является то, что сборщику мусора необходимо «остановить мир» (т.е. приостановить все запущенные потоки), чтобы пометить ссылки из корневых наборов потоков. Это недешево. Таким образом, сборщик мусора не только будет запускаться чаще, но и будет выполнять больше работы с каждой коллекцией.
Другая проблема, конечно, заключается в том, что многопоточные приложения обычно не очень дружелюбны к кешу, что также может существенно снизить производительность.
Я не думаю, что это проблема .NET GC, скорее это проблема с GC в целом. Однажды мой коллега провел простой тест «пинг-понг», отправляя простые целочисленные сообщения между двумя потоками с помощью SOAP. Тест выполнялся в два раза быстрее, когда два потока находились в разных процессах, потому что распределение памяти и управление были полностью разделены!
Не совсем уверен, о чем идет речь и именно то, что вы видели на своей машине. Однако на вашем компьютере есть две различные версии CLR. Mscorwks.dll и mscorsvc.dll. Первый - это тот, который вы получаете, когда запускаете свою программу на рабочей станции, второй - на одной из серверных версий Windows (например, Windows 2003 или 2008).
Версия для рабочей станции удобна для вашего локального ПК, она не поглощает все ресурсы машины. Вы все еще можете читать свою электронную почту, пока идет сборка мусора. Версия сервера оптимизирована для масштабирования на аппаратном уровне сервера. Много оперативной памяти (сборщик мусора не так быстро) и много ядер ЦП (мусор собирается более чем на одном ядре). В цитируемой вами статье, вероятно, говорится о серверной версии.
Вы можете выбрать версию сервера на своей рабочей станции, используя элемент в вашем файле .config.
или объяснить это расхождение между моими прогнозами и наблюдениями?
Сравнительный анализ - это сложно.
Еще сложнее провести сравнительный анализ подсистемы, которая не находится под вашим полным контролем.