Gestione della coda TPL

Question

Ho un servizio che esegue scansioni di vari server. Le reti in questione possono essere enormi (centinaia di migliaia di nodi di rete).

L'attuale versione del software utilizza un'architettura di accodamento/threading progettata da noi che funziona ma non è efficiente come potrebbe essere (non ultimo perché i lavori possono generare figli che non vengono gestiti correttamente)

V2 sta arrivando e sto prendendo in considerazione l'utilizzo del TPL. Sembra che dovrebbe essere idealmente adatto.

Ho visto this question, la risposta alla quale implica che non ci sono limiti alle attività che TPL può gestire. Nei miei semplici test (Spin up di 100.000 task e assegnarli a TPL), TPL è stato messo in discussione abbastanza presto con un'eccezione Out of Memory (abbastanza corretto, specialmente sul mio box di sviluppo).

Le scansioni richiedono un intervallo di tempo variabile ma 5 minuti/compito è una buona media.

Come potete immaginare, le scansioni per reti enormi possono richiedere molto tempo, anche su server muscolosi.

Ho già installato un framework che consente ai processi di scansione (memorizzati in Db) di essere suddivisi tra più server di scansione, ma la domanda è come esattamente dovrei passare il lavoro al TPL su un server specifico.

Posso monitorare la dimensione della coda di TPL e (per esempio) ricaricarla se scende al di sotto di un paio di centinaia di voci? C'è un lato negativo a fare questo?

Devo anche gestire la situazione in cui è necessario mettere in pausa una scansione. Ciò sembra più facile da fare non assegnando il lavoro a TPL piuttosto che annullando/ripristinando attività che potrebbero già essere parzialmente elaborate.

Tutte le attività iniziali possono essere eseguite in qualsiasi ordine. I bambini devono essere eseguiti dopo che il genitore ha iniziato l'esecuzione, ma dal momento che il genitore li genera, questo non dovrebbe mai essere un problema. I bambini possono essere gestiti in qualsiasi ordine. Per questo motivo, attualmente sto immaginando che le attività figlio vengano riscritte sul Db non generato direttamente in TPL. Ciò consentirebbe ad altri server di "rubare" se necessario.

Qualcuno ha avuto esperienza con l'utilizzo della TPL in questo modo? Ci sono delle considerazioni di cui ho bisogno di essere a conoscenza?

Answer 1

TPL si tratta di avviare piccole unità di lavoro e eseguirle in parallelo. È non sul monitoraggio, la sospensione o la limitazione di questo lavoro.

Si dovrebbe vedere TPL come uno strumento di basso livello per avviare "lavoro" e sincronizzare i thread.

Punto chiave: attività TPL! = Attività logiche. Le attività logiche sono nel tuo caso attività di scansione ("scansione di un intervallo di IP da x a y"). Tale attività deve essere non corrispondente a un'attività fisica "System.Threading.Task" perché i due concetti sono diversi.

È necessario pianificare, orchestrare, monitorare e sospendere le attività logiche da soli perché TPL non li capisce e non può essere creato.

preoccupazioni Ora il più funzionale:

1. TPL può certamente iniziare 100k compiti senza OOM.L'OOM è successo perché il codice attività memoria esaurita.
2. Le reti di scansione sembrano un ottimo caso per il codice asincrono, perché mentre si esegue la scansione è probabile che si aspettino risultati con un elevato grado di parallelismo. Probabilmente non vuoi avere 500 thread nel tuo processo in attesa che arrivi un pacchetto di rete. Le attività asincrone si adattano bene al TPL perché ogni attività che esegui diventa puramente legata alla CPU e piccola. Questo è il punto debole per TPL.