[slurm-users] Overzealous PartitionQoS Limits

Christoph Brüning christoph.bruening at uni-wuerzburg.de
Wed May 20 11:38:02 UTC 2020


Quick update:

When we increase the GrpNodes limit, some of the jobs start running.
However, they run on nodes that already have jobs from the "long" 
partition running.
To my understanding, that should node change the node count against 
which the GrpNodes limit is applied...

Best,
Christoph


On 20/05/2020 12.00, Christoph Brüning wrote:
> Dear all,
> 
> we set up a floating partition as described in SLURM's QoS documentation 
> to allow for jobs with a longer than usual walltime on a part of our 
> cluster: QoS with GrpCPUs and GrpNodes limits attached to the 
> longer-walltime partition which contains all nodes.
> 
> We observe that jobs are stuck in the queue like:
> 
> $ squeue -o "%.7i %.9P %.2t %.6C %.20S %R"
>    JOBID PARTITION ST   CPUS           START_TIME NODELIST(REASON)
> 1108810      long PD      2                  N/A (QOSGrpNodeLimit)
> 1108811      long PD      2                  N/A (QOSGrpNodeLimit)
> 1108812      long PD      2                  N/A (QOSGrpNodeLimit)
> 1108813      long PD      2                  N/A (QOSGrpNodeLimit)
> 1108814      long PD      2                  N/A (QOSGrpNodeLimit)
> 1108815      long PD      2                  N/A (QOSGrpNodeLimit)
> 1108816      long PD      2                  N/A (QOSGrpNodeLimit)
> 1108817      long PD      2                  N/A (QOSGrpNodeLimit)
> 1108818      long PD      2                  N/A (QOSGrpNodeLimit)
> [...]
> 
> However, we are not even close to any of the GrpNodes or GrpCPUs limits.
> And there are nodes in MIXED state that should have slots for two-CPU 
> jobs available.
> The mentioned jobs even have the highest priority (except for two jobs 
> on a special-hardware partition), and they have an empty "Dependency=" 
> field.
> 
> It seems that those jobs are occasionally assigned a start time when the 
> scheduler runs, but that is quickly reverted to "N/A".
> 
> Did any of you observe this or similar behaviour?
> FWIW, we are running SLURM 17.11 on Debian, an upgrade to 19.05 is 
> scheduled in the next couple of weeks.
> 
> Best,
> Christoph
> 
> 

-- 
Dr. Christoph Brüning
Universität Würzburg
Rechenzentrum
Am Hubland
D-97074 Würzburg
Tel.: +49 931 31-80499



More information about the slurm-users mailing list