Istnieje wiele powodów, dla których zadanie może nie być uruchamiane od razu po wstawieniu do kolejki. Na niektóre z nich użytkownik ma wpływ, na inne nie. Slurm udziela nam wskazówek dlaczego zadanie czeka. Po wpisaniu polecenia squeue przyczyna znajduje się w kolumnie NODELIST(REASON)

Komunikat ten oznacza, że w systemie istnieje rezerwacja i zadanie nie zdążyłoby się wykonać przed jej rozpoczęciem. Rezerwacje tworzą administratorzy, gdy zachodzi potrzeba wykonania czynności konserwatorskich na pustym klastrze (np. restart maszyn). Tworzą wówczas rezerwację konserwatorską (ang. maintaince), która zapewni, że w zaplanowanym terminie klaster będzie pusty i będzie można go bezpiecznie wykonać prace bez zmarnowania czyichś obliczeń. Kłopot polega na tym, że SLURM nie wie ile czasu będzie trwało zadanie użytkownika. Jeśli użytkownik nie poda szacunkowego terminu zakończenia, to SLURM przyjmuje maksymalny czas dozwolony w ramach kolejki. Jeśli ten czas jest dłuższy niż czas do rozpoczęcia rezerwacji, to SLURM nie wpuści zadania na klaster, bo uzna, że nie zdążyłoby się wykonać przed początkiem rezerwacji. Zadanie będzie czekać, aż do zakończenia prac, nawet jeśli faktyczne obliczenia zakończyłyby się przed rozpoczęciem rezerwacji.

Jeśli tylko jesteś w stanie wskazać górne ograniczenie czasu wykonania zadania (mniejsze niż maksymalny czas w kolejce) to należy to zrobić. Im dokładniejsze oszacowanie, tym lepiej SLURM zaplanuje uruchamianie zadań.

1. Sprawdź jakie rezerwacje znajdują się w systemie: scontrol show res
2. Sprawdź limity czasu w kolejkach: sinfo
3. Sprawdź najpóźniej wykona się Twoje zadanie: squeue --start
4. Wykonaj próbę uruchomienia zadania z flagą --test-only. Flaga powoduje sprawdzenie poprawności pliku batch, oraz zwraca szacunkowy termin uruchomienia zadania. W różnych kolejkach to samo zadanie może mieć inny termin uruchomienia, dlatego warto sprawdzać!
5. Dodaj do swojego zadania flagę ograniczającą czas zadania: -t/--time lub dyrektywę #SBATCH --time. Dostępne formaty argumentu to:
   • minutes
   • minutes:seconds
   • hours:minutes:seconds
   • days-hours
   • days-hours:minutes
   • days-hours:minutes:seconds

Wszystkie wymienione powyżej uwagi i wskazówki mają zastosowanie i w tym wypadku. Różnica tkwi w przyczynie utworzenia rezerwacji. Niektóre przedsięwzięcia wymagają dostępności określonych zasobów w konkretnym czasie. W uzasadnionych wypadkach administrator może wykonać taką rezerwacje na prośbę użytkownika.

Użytkownik zażądał zasobów niemożliwych do spełnienia w ramach danej kolejki. Np. zbyt wiele węzłów obliczeniowych.

Użytkownik zażądał czasu dla zadania dłuższego niż limit kolejki.

1. Należy sprawdzić parametry zadania i skonfrontować je z konfiguracją kolejki
2. Parametry kolejek można wyświetlić przy pomocy polecenie scontrol show partition

Ten komunikat oznacza typową sytuację gdy na klastrze trwają inne obliczenia i zadanie czeka na ich zwolnienie. Żadna akcja ze strony użytkownika nie jest wymagana. Warto się jednak upewnić, czy nie blokujemy sami siebie zbyt “frywolnym” specyfikowaniem zasobów. Np. wymagamy zbyt dużej liczby RAM, albo żądamy konkretnego węzła podczas gdy równie dobrze moglibyśmy zrealizować je na dowolnym innym.

Komunikat oznacza, że zadanie zostało zepchnięte w dół listy priorytetów. Szczegółowy opis algorytmu obliczania priorytetu pojawi się niebawem. Aby sprawdzić jakie wartości składowe wpływają na obliczenie priorytetu zadania należy wpisać polecenie sprio.