2010-01-11 12 views
26

¿Hay un número mágico o fórmula para establecer los valores de SetMaxThreads y SetMinThreads para ThreadPool? Tengo miles de métodos de larga ejecución que necesitan ejecución, pero simplemente no puedo encontrar la combinación perfecta para establecer estos valores. Cualquier consejo sería muy apreciado.ThreadPool SetMaxThreads y SetMinThreads Número mágico

Respuesta

39

El número mínimo predeterminado de subprocesos es la cantidad de núcleos que tiene su máquina. Es un buen número, generalmente no tiene sentido ejecutar más hilos que núcleos.

El número máximo predeterminado de subprocesos es 250 veces el número de núcleos que tiene en .NET 2.0 SP1 y superiores. Hay una enorme cantidad de espacio para respirar aquí. En una máquina de cuatro núcleos, tomaría 499 segundos alcanzar ese máximo si ninguno de los hilos se completa en un período de tiempo razonable.

El programador de subprocesos trata de limitar el número de subprocesos activos al mínimo, de forma predeterminada, la cantidad de núcleos que tiene. Dos veces por segundo permite que se inicie un hilo más si los hilos activos no se completan. Los subprocesos que se ejecutan durante mucho tiempo o que bloquean mucho que no son causados ​​por E/S no son buenos candidatos para el grupo de subprocesos. Deberías usar un Thread normal en su lugar.

Llegar al máximo no es saludable. En una máquina de cuatro núcleos, solo las pilas de esos hilos consumirán un gigabyte de espacio de memoria virtual. Obtener OOM es muy probable. Considere reducir la cantidad máxima de hilos si ese es su problema. O considere comenzar unos pocos subprocesos regulares que reciben paquetes de trabajo de una cola segura para subprocesos.

+0

Mire [mi pregunta relacionada] (http://stackoverflow.com/q/7974559/75500 " Ejecutar un lote de procesos e informar el progreso de cada uno de ellos "), un usuario sugirió que debería usar el [ThreadPool], de acuerdo con lo que diga, no creo que sea una buena idea, quizás pueda ayudarme. – Shimmy

+3

@ Hans Passant: esto es apenas correcto, antes que nada t El número máximo predeterminado de subprocesos depende de la versión de .NET Framework utilizada por la aplicación (p. 25 por núcleo en 2.0). En segundo lugar, aumentar el número mínimo de subprocesos permite que los subprocesos se puedan iniciar sin demora hasta que se alcanza el número mínimo (no se lanzarán si no se necesitan). Si se alcanza la demora mínima, los hilos nuevos solo se crearán con un retraso intermedio, lo que resultará en un aumento del rendimiento en operaciones largas (> 500ms), pero en una caída de rendimiento en operaciones cortas. – haze4real

+0

@HansPassant: si uno está creando hilos que pueden bloquearse esperando un IO externo, creo que hay situaciones en las que el "mejor" mínimo sería de hecho mayor que el número de núcleos. Porque un hilo "bloqueado" todavía "cuenta" hacia el mínimo, ¿verdad? (Entiendo que esto no importará por más de unos pocos segundos, porque después de eso, el programador habrá creado esos hilos adicionales de todos modos. Solo me aseguro de entender el razonamiento). – ToolmakerSteve

6

Normalmente, el número mágico es dejarlo solo. El ThreadPool hace un buen trabajo al manejar esto.

Dicho esto, si usted está haciendo un montón de servicios de larga ejecución, y esos servicios tendrán períodos largos en los que están esperando, es posible que desee aumentar el número máximo de hilos para manejar más opciones. (Si los procesos no están bloqueando, probablemente disminuirá la velocidad si aumenta el número de subprocesos ...)

Haga un perfil de su aplicación para encontrar el número correcto.

+0

Si tuviera que cambiar los hilos max (y los hilos mínimos?) Hay dos parámetros, subprocesos de trabajo y subprocesos de puerto de finalización. ¿Cuál es el número de hilos del puerto de finalización? – Benny

+0

Además, si dejo el ThreadPool solo, sin establecer subprocesos mínimo/máximo, me encuentro con una excepción OutOfMemoryException y todos los subprocesos fallan. – Benny

+3

Ese es un problema diferente: puede reducir la cantidad de trabajo estrangulándolo, pero quedarse sin memoria realmente no tiene nada que ver con enhebrar ... –

5

Si desea un mejor control, es posible que desee considerar NO utilizar el ThreadPool incorporado. Hay un buen reemplazo en http://www.codeproject.com/KB/threads/smartthreadpool.aspx.

+0

Intenté usar SmartThreadPool, pero fue en vano. Después de poner en cola todos los elementos de trabajo, intenté usar WaitForIdle (tengo una lógica posterior a la ejecución para ejecutar) y nunca bloquea , simplemente se mueve hacia la derecha. Puede estar entre el teclado y la computadora, pero aún no lo ha descubierto – Benny

Cuestiones relacionadas