Saldo del carico di lavoro / Algoritmo di distribuzione delle attività

Una parte di ciò che stai cercando è una coda di priorità ". Ai precedenti datori di lavoro, abbiamo fatto una versione molto primitiva di questo, ma la mia euristica consisteva nel consentire solo ad alcuni processori di gestire lavori di breve durata (i lavori corti potevano richiedere minuti), mentre altri stavano gestendo lavori più lunghi (il rapporto trimestrale potrebbe richiedere quasi 2 giorni per elaborare). Questo garantiva che i lavori brevi avessero sempre tempo di elaborazione disponibile. Ho anche usato un tabellone segnapunti che elencava i lavori pronti per essere eseguiti, e il primo processore in grado di gestire l'attività lo avrebbe raccolto ed eseguito in un singolo thread (erano computer economici che non erano stati ammortizzati e quindi non potevano essere scartati). Molte persone usano il contrario: un programmatore che indica ai processori quale unità lavorativa dovrà eseguire successivamente. Il mio consiglio è di fare in modo che ogni istanza esegua una singola attività: ciò semplifica drasticamente la pianificazione.

La pianificazione di lavori arbitrari di lunghezze arbitrarie è un problema difficile nell'elaborazione distribuita. Quasi ogni decisione coinvolgerà la simulazione di molte corse. Qual è uno dei capricci della teoria delle code, su cui si baserà questa roba.

One of the other devs suggested we leave the "job processors" alone to just pull whatever is in the queue next or "round robin". I say that this could lead to a potential issue where a single instance has pulled down too many large jobs and is struggling to get them done while the other instances are idle.

Questo richiede una simulazione per rispondere. Il mio schema precedente usava qualcosa di molto simile. Se si dispone di statistiche sulle corse di lavoro precedenti, è possibile modellarle in Excel. Ho raccolto questo libro da un altro post che lo consiglia e sto cercando di imparare alcune tecniche per essere in grado di rispondere a problemi come quello che stai descrivendo. I numeri reali superano tutto, quindi raccogli dati e fai simulazioni basate su di essi.

Penso che il tuo ragionamento sia valido e che la tua idea sia buona e l'idea dell'amico sia abbastanza buona.

Forse dovresti considerare anche un processo "Pre-processo"?

Se i lavori impiegano così tanto tempo a causare un tempo di attesa non necessario nella coda, potrebbe essere possibile suddividere un singolo grande lavoro in una serie di lavori più piccoli che prelevano i dati in tabelle di staging per il processo principale.

Ridurre il costo di un singolo lavoro in modo che la disparità dei tempi medi di elaborazione sia molto più bassa sarebbe un'alternativa considerevole a un sistema di classificazione.

EDIT: Vorrei anche notare che un sistema di classificazione derivato da Time per Job può essere strongmente influenzato da variabili specifiche dell'ambiente, (ad esempio, un lavoro classificato basso a causa dell'accesso I / O su un server con configurazione RAID potrebbe non avere una classifica che abbia senso su un server con un HDD a stato solido.)

Questo può essere un trabocchetto nel dermining rank basato sulle prestazioni di un singolo ambiente.

Add more instances of the "job processor". We have a big VM server that IT is rolling out 3 VM's to each handle an instance of this "job processor".

Una corretta.

By default, it's going to help but I believe that there should be more thought behind it.

non corretto.

Qualsiasi altra ingegneria è una perdita di tempo assoluta.

Considera i casi d'uso in dettaglio.

Su una coda di processore singolo, il lavoro di lunga durata entra prima nel processore one-and-only. Altri lavori aspettano. Non ti piace.

In una coda con più processori, il lavoro di lunga durata entra in uno dei processori, lasciando gli altri liberi. Problema risolto.

Supponiamo che tu abbia tre lavori di lunga durata che potrebbero iniziare contemporaneamente. Quindi, hai semplicemente bisogno di 4 processori per gestire il carico di lavoro. Tre otterranno lavori di lunga durata, il quarto gestirà i lavori "istantanei".

Più processori che lavorano da una singola coda di richieste è la soluzione standard, ampiamente adottata, quasi universale. Niente di più è necessario.

Se pensi davvero che le priorità siano importanti, usi una coda di priorità invece di una coda FIFO e assegni manualmente priorità semplici. Non pensarci troppo. Più pensare sarà semplicemente una perdita di tempo.