5

Tengo un servicio que ejecuta escaneos de varios servidores. Las redes en cuestión pueden ser enormes (cientos de miles de nodos de red).Administración de TPL Queue

La versión actual del software está utilizando una arquitectura de cola/subprocesamiento diseñada por nosotros que funciona pero no es tan eficiente como podría (no menos importante porque los trabajos pueden generar hijos que no se maneja bien)

V2 se acerca y estoy considerando usar el TPL. Parece que debería ser ideal.

He visto this question, cuya respuesta implica que no hay límite para las tareas que TPL puede manejar. En mis pruebas simples (tareas Spin up 100,000 y dárselas a TPL), TPL sufrió un error desde el principio con una excepción de falta de memoria (lo suficientemente justo, especialmente en mi cuadro dev).

The Scans toma un tiempo variable pero 5 minutos/tarea es un buen promedio.

Como se puede imaginar, las exploraciones de grandes redes pueden llevar un tiempo considerable, incluso en servidores fornidos.

Ya tengo un marco que permite que los trabajos de escaneo (almacenados en un Db) se dividan entre varios servidores de escaneo, pero la pregunta es cómo exactamente debo pasar el trabajo al TPL en un servidor específico.

¿Puedo controlar el tamaño de la cola de TPL y (por ejemplo) completarla si cae por debajo de un par de cientos de entradas? ¿Hay algún inconveniente para hacer esto?

También necesito manejar la situación en la que se debe pausar un escaneo. Esto parece más fácil de hacer al no entregar el trabajo a TPL que al cancelar/restablecer tareas que ya pueden estar parcialmente procesadas.

Todas las tareas iniciales se pueden ejecutar en cualquier orden. Los niños deben correr después de que el padre haya comenzado a ejecutar, pero dado que el padre los engendra, esto nunca debería ser un problema. Los niños pueden correr en cualquier orden. Debido a esto, actualmente estoy visualizando que las tareas secundarias se vuelvan a escribir en el Db que no se generó directamente en TPL. Esto permitiría a otros servidores "robar trabajo" si es necesario.

¿Alguien ha tenido alguna experiencia con el uso del TPL de esta manera? ¿Hay alguna consideración que deba tener en cuenta?

+0

Programar miles de 'Tareas', donde cada una puede tomar varios minutos probablemente no sea una buena idea. En tal caso, el TPL programará nuevas 'Tareas' una y otra vez, lo que probablemente no sea una buena idea en su caso. – svick

+0

No tengo claro si un escaneo determinado (una tarea que se ejecuta durante aproximadamente 5 minutos) pasa la mayor parte del tiempo en E/S esperando que las cosas vuelvan de la red o la mayor parte del tiempo en la CPU analizando cosas. Un par de otros marcos que podría considerar que podrían ser más adecuados para esto serían TPL DataFlow y Reactive Extensions 2.0. Si puede dar un código que muestre cómo se vería un escaneo dado (al menos en términos de un pseudocódigo para determinar qué tipo de equilibrio IO/CPU tiene), eso puede ayudar a otros a dar una mejor dirección, también. –

+0

@JamesManning Disculpas, debería haberlo aclarado ...> el 99% de los 5 minutos está esperando en la red IO – Basic

Respuesta

10

TPL consiste en iniciar pequeñas unidades de trabajo y ejecutarlas en paralelo. Es no sobre la supervisión, pausar o estrangular este trabajo.

Debería ver TPL como una herramienta de bajo nivel para comenzar a "trabajar" y sincronizar los hilos.

Punto clave: tareas TPL! = Tareas lógicas. Las tareas lógicas se encuentran en las tareas de escaneo de su caso ("escanear un rango de ip de xa y"). Tal tarea debe no corresponde a una tarea física "System.Threading.Task" porque los dos son conceptos diferentes.

Necesita programar, orquestar, supervisar y pausar las tareas lógicas usted mismo porque TPL no las entiende y no se puede hacer.

preocupaciones Ahora el más funcional:

  1. TPL sin duda puede empezar a 100k tareas sin OOM.El OOM sucedió porque el código de sus tareas memoria agotada.
  2. Las redes de escaneo suenan como un gran caso para el código asíncrono porque, mientras escanea, es probable que espere los resultados mientras tiene un alto grado de paralelismo. Probablemente no desee tener 500 hilos en su proceso, todos esperando que llegue un paquete de red. Las tareas asincrónicas se ajustan bien al TPL porque cada tarea que ejecuta se convierte en algo limitado a la CPU y pequeño. Ese es el punto ideal para TPL.
+0

Gracias, en resumen, adaptaré mi biblioteca existente y seguiré programando, etc. de la forma en que lo es, pero solo transfiera la administración de hilos a TPL. – Basic

+0

@Basic, en realidad sí ;-) Si C# 5 está disponible para ti, hacer el código asincrónico es bastante fácil. Si no está en v5, puede ver el patrón "intey async" como una solución alternativa (http://blogs.msdn.com/b/pfxteam/archive/2009/06/30/9809774.aspx). – usr

+0

Gracias, sí, estoy apuntando a .Net 4.5 ya - ¿Por qué no desde que se está trabajando en una reescritura? Además, me gusta mucho el nuevo 'ApiController' en MVC;) – Basic