CapordiaScrivere il contratto minimo di una richiesta
Una richiesta utilizzabile nomina un proprietario, un progetto, un input disponibile, un comando o una procedura identificata e un risultato atteso. Indica il numero di GPU simultanee, la memoria per GPU, la durata stimata e la destinazione degli output. Specifica infine la scadenza, il motivo di tale scadenza e la persona autorizzata ad accettare un ritardo o una riduzione del perimetro.
L'assenza di queste informazioni non deve essere nascosta da una priorità elevata. Un'attività i cui input non sono pronti resta non ammissibile, anche se il progetto è importante. Chiedi cosa manca e fissa il punto di ricontrollo. La coda diventa così uno strumento decisionale: non si trasforma in un magazzino di richieste impossibili da avviare che ognuno spera vengano trattate spontaneamente.
Distinguere ammissione, prenotazione e diritto di passaggio
L'ammissione verifica che l'attività possa essere esaminata: diritti, dati, compatibilità, capacità e procedura presenti. Una prenotazione protegge poi una fascia oraria o una risorsa decisa. La priorità sceglie l'ordine tra le richieste ammissibili che si contendono una risorsa disponibile. Queste tre decisioni possono dipendere da persone diverse; rendi esplicita questa ripartizione per evitare una validazione implicita del bisogno tecnico.
Una GPU libera non rende ammissibili tutte le attività. Il disco necessario può mancare, una licenza può limitare la concorrenza o il risultato precedente può essere richiesto. Al contrario, una richiesta tecnicamente pronta può attendere una decisione di calendario. Mostra un motivo comprensibile e una prossima azione, invece di un semplice rango numerico che nessuno sa interpretare.
Definire priorità che non diventino privilegi
Scegli poche classi leggibili, ad esempio scadenza esterna confermata, lavoro corrente ed esplorazione senza data ferma. Determina chi può assegnare una classe e quale elemento la giustifica. All'interno di una classe, una regola di anzianità o di rotazione può rendere la scelta prevedibile. Una richiesta suddivisa in cento piccole sottomissioni non deve ottenere meccanicamente cento volte più possibilità di una richiesta di un'altra squadra.
Slurm distingue in particolare l'età di attesa ammissibile e la condivisione equa basata sulle risorse assegnate e consumate. Questo illustra due domande diverse: da quando si aspetta, e quale quota si è già utilizzata? La tua regola può restare manuale. Non riprendere una formula di punteggio senza capirne i parametri; i pesi di uno scheduler particolare non costituiscono una norma di equità universale.
Esempio fittizio: far entrare un'urgenza senza scacciare gli altri
La squadra fittizia «Plans et repères» utilizza una sola GPU. Alle 9, un'attività del progetto Plans ha una fascia confermata fino alle 11; non è interrompibile. Due richieste complete attendono: Repères, quaranta minuti, ed Esquisses, ottanta minuti. Alle 9:30 arriva un'urgenza di trenta minuti, richiesta da Repères per una revisione a mezzogiorno. Tutti questi tempi sono ipotesi didattiche, non misurazioni.
La regola locale autorizza un'urgenza convalidata a passare al prossimo punto di rilascio, senza interrompere un lavoro già avviato. L'urgenza parte quindi alle 11 e finisce teoricamente alle 11:30. La squadra concede poi il passaggio a Esquisses per evitare che Repères, già servito con la sua urgenza, monopolizzi la coda. Questa eccezione e la nuova partenza attesa di Repères sono annunciate ai responsabili interessati.
| Fascia ipotetica | Progetto | Motivo del passaggio |
|---|---|---|
| 9–11 | Plans | Fascia già impegnata, non interrompibile |
| 11–11:30 | Repères, urgenza | Scadenza esterna confermata prima di mezzogiorno |
| 11:30–12:50 | Esquisses | Rotazione dopo l'urgenza servita a Repères |
| 12:50–13:30 | Repères, richiesta corrente | Richiesta ammissibile successiva |
Prevenire la fame dei lavori lunghi
Servire sistematicamente la richiesta più breve produce una coda apparentemente fluida ma può rimandare indefinitamente un lavoro lungo. Prevedi finestre riservate o un riesame a partire da un'età di attesa annunciata. Questa soglia è una regola interna da definire, non un tempo di servizio garantito. Se il lavoro lungo supera realmente la finestra disponibile, la sua ammissione deve portare a un nuovo calendario anziché a un'attesa senza sbocco.
I vuoti brevi possono accogliere attività che non rimandano una partenza riservata. Questa decisione presuppone una stima credibile, una risorsa realmente compatibile e la possibilità di terminare entro la finestra. Non riempire tutti i margini del calendario con nuovi impegni. Una riserva destinata ad assorbire uno scarto non è uno slot gratuito; il suo utilizzo deve avere un responsabile e una conseguenza nota.
Prevedere un annullamento dal perimetro chiaro
Stabilisci chi può annullare la propria richiesta, quella di un progetto o un'esecuzione diventata pericolosa per gli altri lavori. Per una richiesta ancora in attesa, conferma la sua rimozione dall'ordine di passaggio. Per un lavoro avviato, verifica prima cosa è interrompibile, cosa va conservato e chi attende i suoi output. Un messaggio «annullamento richiesto» non prova ancora che la risorsa sia libera.
Lo strumento reale determina gli effetti tecnici. La documentazione di scancel distingue un lavoro e le sue fasi, nonché l'invio di un segnale e l'annullamento del lavoro. Prima di usare uno strumento equivalente, controlla l'identificativo e il perimetro interessati; evita una selezione globale per comodità. Verifica poi la fine dei processi e la destinazione degli output parziali. Il piano di ripresa dei dati è trattato nel dossier di migrazione, separatamente da questa regola di priorità.
Limitare i tentativi e isolare un'attività difettosa
Decidi prima dell'esecuzione quanti tentativi automatici sono accettabili per la stessa causa. Un input non valido non diventa corretto perché lo si rilanciar; una dipendenza temporaneamente inaccessibile può giustificare un nuovo tentativo dopo verifica. La regola deve indicare il numero massimo, l'eventuale tempo di attesa e il responsabile del riesame. Un contatore azzerato a ogni nuova sottomissione annulla questa protezione: collega le richieste successive allo stesso problema.
Al limite deciso, rimuovi l'attività difettosa dalla concorrenza normale e mettila in quarantena logica, con un motivo leggibile. Il resto dei lavori ammissibili può continuare. La reintegrazione richiede una correzione o una spiegazione convalidata, un piccolo controllo mirato e una decisione del proprietario; non riprende automaticamente la priorità di un'urgenza vecchia. Questa procedura regola l'ammissione dopo un fallimento. La conservazione degli output e la loro ripresa restano nel dossier di migrazione, senza inventare qui un nuovo registro di stati.
Testare la politica con quattro situazioni semplici
Fai rileggere la regola ai responsabili di progetto con quattro casi: due richieste identiche, un'urgenza durante un lavoro non interrompibile, un'attività lunga circondata da richieste brevi e una richiesta incompleta classificata urgente. Per ogni caso, una persona diversa deve giungere alla stessa partenza successiva o identificare esplicitamente l'arbitrato richiesto. Una regola che solo il suo autore comprende non è pronta per essere applicata.
Controlla inoltre che un annullamento non conceda due volte la stessa capacità e che un lavoro bloccato non impedisca inutilmente un altro lavoro ammissibile. Queste verifiche possono iniziare sulla carta; non provano l'implementazione di uno scheduler. Se in seguito automatizzi, riproduci gli stessi scenari sullo strumento configurato prima di farvi dipendere un impegno di progetto.
Misurare il servizio reso dalla coda
Monitora l'attesa delle richieste ammissibili per classe e per progetto, così come i motivi di blocco. Separa attesa, occupazione e tempo fino al risultato accettato. Un unico totale di lavori completati può mascherare un team sempre rimandato o un accumulo di attività urgenti. Esamina anche gli scostamenti tra occupazione stimata e reale: influenzano direttamente le prenotazioni future.
Rivedi la politica a una scadenza scelta con il team, o dopo un incidente che rivela una regola mancante. Cambia una regola alla volta e annuncia il suo effetto sulle richieste già presenti. Il risultato atteso è un ordine di passaggio spiegabile, eccezioni tracciabili e un calendario coerente. Non sostituisce né l'autenticazione dell'account Capordia né i permessi della macchina, e non crea alcun impegno di supporto.
Domande per decidere
Un'urgenza deve sempre passare per prima?
Un'urgenza deve essere ammissibile, giustificata e convalidata secondo la regola comune. Non rende interrompibile un lavoro in corso. Definisci il suo punto di passaggio, le richieste spostate e la persona che si assume l'effetto sulle loro scadenze.
Come evitare che un team monopolizzi le fasce orarie?
Guarda le risorse già ottenute e l'attesa degli altri progetti, poi usa una rotazione o una regola di condivisione esplicita. Il numero grezzo di richieste non è una misura di equità. Prevedi anche la gestione dei lavori lunghi.
Questo metodo impone di installare Slurm?
No. I documenti Slurm chiariscono alcune distinzioni, ma la politica può essere applicata innanzitutto nello strumento di coordinamento del team. Un'eventuale automazione richiede una propria configurazione e i propri controlli; nessuno scheduler si presume fornito.