Должны ли мы использовать сборку мусора или сборку мусора на "рабочей станции"?

У меня есть большое многопоточное приложение С#, работающее на многоядерном четырехстороннем сервере. В настоящее время мы используем сборку мусора "режим сервера". Однако тестирование показало, что режим рабочей станции GC быстрее.

MSDN говорит:

Приложения с управляемым кодом, использующие API-интерфейс сервера, получают значительные преимущества от использования сборщика мусора (GC), оптимизированного сервером, вместо GC рабочей станции по умолчанию.

Рабочая станция - это режим GC по умолчанию и единственный доступный на однопроцессорных компьютерах. Рабочая станция GC размещена в консольных приложениях Windows Forms. Он выполняет полную (генерацию 2) коллекции одновременно с запущенной программой, тем самым минимизируя задержку. Этот режим полезен для клиентских приложений, где воспринимаемая производительность обычно более важна, чем сырая пропускная способность.

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

Но мы не видим блеска производительности!!!! Кто-нибудь получил какие-либо советы?

Ответ 1

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

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

Режим сервера предназначен для приложений, где каждое "задание" относительно недолговечно и обрабатывается одним ядром (редактирование: подумайте о многопоточном веб-сервере). Идея состоит в том, что каждая "работа" получает всю мощь процессора и выполняется быстро, но иногда ядро перестает обрабатывать запросы и очищает память. Таким образом, в этом случае мы надеемся, что GC в среднем эффективнее, но ядро недоступно во время его запуска, поэтому приложение должно быть в состоянии адаптироваться к этому.

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

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

Ответ 2

.NET 4.5 представляет сборку мусорных сборок сервера.

http://msdn.microsoft.com/en-us/library/ee787088.aspx

specify <gcServer enabled="true"/> 
specify <gcConcurrent enabled="true"/> (this is the default so can be omitted)

И есть новый SustainedLowLatencyMode;

В .NET Framework 4.5 режим SustainedLowLatency доступен как для рабочей станции, так и для сервера GC. Чтобы включить его, установите для свойства GCSettings.LatencyMode значение GCLatencyMode.SustainedLowLatency.