¿Deberíamos utilizar la recolección de basura "estación de trabajo" o la recolección de basura "servidor"?

Question

Tengo una gran aplicación C# multiproceso que se ejecuta en un servidor de 4 vías multinúcleo. Actualmente estamos utilizando la recolección de basura "en modo servidor". Sin embargo, las pruebas han demostrado que el modo de estación de trabajo GC es más rápido.

MSDN says:

aplicaciones de código administrado que utilizan la API de servidor reciben importantes beneficios de usar el colector optimizado servidor de basura (GC) en lugar del GC estación de trabajo predeterminado.

La estación de trabajo es el modo predeterminado de GC y el único disponible en las computadoras de un solo procesador. Workstation GC está alojado en la consola y en las aplicaciones de Windows Forms. Realiza colecciones completas (generación 2) al mismo tiempo que el programa en ejecución, lo que minimiza la latencia. Este modo es útil para aplicaciones de clientes, donde el rendimiento percibido suele ser más importante que el rendimiento sin procesar.

El servidor GC está disponible solo en computadoras multiprocesador. Crea un montón e hilo administrado por separado para cada procesador y realiza colecciones en paralelo. Durante la recopilación, todos los subprocesos administrados se ponen en pausa (los subprocesos que ejecutan código nativo se pausan solo cuando regresa la llamada nativa). De esta forma, el modo GC del servidor maximiza el rendimiento (el número de solicitudes por segundo) y mejora el rendimiento a medida que aumenta el número de procesadores. El rendimiento especialmente brilla en computadoras con cuatro o más procesadores.

Pero no estamos viendo el brillo de rendimiento !!!! ¿Alguien tiene algún consejo?

Answer 1

No se explica muy bien, pero hasta donde puedo decir, el modo de servidor es sincrónico por núcleo, mientras que el modo de estación de trabajo es asincrónico.

En otras palabras, el modo de estación de trabajo está destinado a un pequeño número de aplicaciones de larga ejecución que necesitan un rendimiento constante. La recolección de basura trata de "mantenerse fuera del camino" pero, como resultado, es menos eficiente en promedio.

El modo de servidor está destinado a aplicaciones en las que cada "trabajo" tiene una vida relativamente corta y se maneja con un único núcleo (edit: think multi-threaded web server). La idea es que cada "trabajo" tenga toda la potencia de la CPU y se realice rápidamente, pero ocasionalmente el núcleo deja de atender solicitudes y limpia la memoria. Entonces, en este caso, la esperanza es que GC sea más eficiente en promedio, pero el núcleo no está disponible mientras se está ejecutando, por lo que la aplicación debe ser capaz de adaptarse a eso.

En su caso, parece que, debido a que tiene una sola aplicación cuyos hilos están relativamente acoplados, se ajusta mejor al modelo esperado por el primer modo que por el segundo.

Pero eso es todo justificación después del hecho. Mida el rendimiento de su sistema (como dijo ammoQ, no el rendimiento de su GC, sino cómo se comporta su aplicación) y use lo que mide para ser el mejor.

Answer 2

.NET 4.5 presenta la recolección de basura del servidor concurrente.

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) 

Y no es el nuevo SustainedLowLatencyMode;

En .NET Framework 4.5, el modo SustainedLowLatency está disponible tanto para la estación de trabajo como para el servidor GC. Para activarlo, configure GCSettings.LatencyMode property to GCLatencyMode.SustainedLowLatency.