Hello @Njiva.Andrianarivelo,
Thank you for raising your concern.
First, I would like to kindly remind that the forum is intended for technical discussions and user support, not for publicly singling out individual users. If you have identified a specific user and believe there may be an issue, please send us the relevant details by email, we will be happy to review the situation.
Regarding the situation you observed, the current behavior appears to be consistent with Slurm’s scheduling policies.
Slurm does not schedule jobs purely on a first-come, first-served basis. Job priority is computed from several factors, including:
- Fairshare usage
- Job age (time spent waiting in the queue)
- Partition and QoS settings
- Requested resources
- Other site-specific scheduling parameters
The following command may help to better understand how Slurm computes job priorities:
(bamboo)-[root@admin1 ~]$ sprio -l
JOBID PARTITION USER ACCOUNT PRIORITY SITE AGE ASSOC FAIRSHARE JOBSIZE PARTITION QOSNAME QOS NICE TRES
3991335 shared-gp vador Palpatine 430376 0 38599 0 16768 9 375000 normal 0 0
4026427 shared-gp maul Palpatine 376508 0 1475 0 0 34 375000 normal 0 0
4026478 shared-gp Assaj_Ven+ Palpatine 378424 0 3416 0 0 9 375000 normal 0 0
One important factor is job age: jobs that remain in the queue for a longer period gradually gain priority. After reviewing the queue, I observed that this user’s jobs had been waiting longer than several other pending jobs, which contributed to their higher priority when resources became available.
It is also worth noting that the user is not exclusively occupying all GPU resources, as GPU jobs from other users are running at the same time.
In addition, Slurm uses a backfill scheduler. This mechanism continuously re-evaluates the queue and starts jobs whenever it can do so without delaying higher-priority reservations. The objective is to maximize cluster utilization while preserving scheduling fairness. As a result, it is not unusual to see multiple jobs from the same user start simultaneously when resources become available.
Another important aspect is the requested walltime and resources. The backfill scheduler can generally place jobs more easily when they request realistic resource requirements and an accurate walltime estimate. Conversely, jobs requesting significantly more resources than needed, or requesting the maximum walltime allowed by the partition, are often more difficult to fit into the schedule and may remain queued longer. Therefore, accurately estimating resource requirements and walltime is beneficial both for cluster efficiency and for reducing scheduling delays.
Finally, many users submit workloads through sbatch, often using job arrays. These jobs can remain in the queue for extended periods and continue to accumulate priority while waiting. This is expected behavior and is one of the reasons why batch submission is generally recommended for large-scale workloads.
Best regards,