Hi Gérard,
If I understood you correctly your goal was to limit the number of minutes each
project can run. By associating each project to a slurm account with a nodecay
QoS then you will have achieved your goal.
Try a project with a very small limit and you will see that it won’t run.
You don’
On 28/6/22 12:19 pm, Jean-Christophe HAESSIG wrote:
Hi,
I'm facing a weird issue where launching a job through drmaa
(https://github.com/natefoo/slurm-drmaa) aborts with the message "Plugin
is corrupted", but only when that job is placed from one of my compute
nodes. Running the command from th
Hi Miguel,
OK, I did'nt know this command.
I'm not sure to understand how it works regarding to my goal.
I use the following command inspired by the command you gave me and I obtain a
UsageRaw for each QOS.
scontrol -o show assoc_mgr -accounts=myaccount Users=" "
Do I have to sumup all QO
Hi,
I'm facing a weird issue where launching a job through drmaa
(https://github.com/natefoo/slurm-drmaa) aborts with the message "Plugin
is corrupted", but only when that job is placed from one of my compute
nodes. Running the command from the login node seems to work.
My cluster runs Slurm 2
Hi Gérard,
The way you are checking is against the association and as such it ought to be
decreasing in order to be used by fair share appropriately.
The counter used that does not decrease is on the QoS, not the association. You
can check that with:
scontrol -o show assoc_mgr | grep "^QOS='+ac
Hi Miguel,
I modified my test configuration to evaluate the effect of NoDecay.
I modified all QOS adding NoDecay Flag.
toto@login1:~/TEST$ sacctmgr show QOS
Name Priority GraceTime Preempt PreemptExemptTime PreemptMode Flags UsageThres
UsageFactor GrpTRES GrpTRESMins GrpTRESRunMin GrpJobs G
