t; De: "Gérard Gil"
> À: "Miguel Oliveira"
> Cc: "Slurm-users"
> Envoyé: Vendredi 1 Juillet 2022 11:03:42
> Objet: Re: [slurm-users] GrpTRESMins and GrpTRESRaw usage
> Hi Miguel,
> As far as I understood GrpTRESMins=cpu=N(4227) seems not to be the li
ASON START_TIME
>> 3687 BDW28 6M 2022-06-30T19:36:42 110 bdw28 support toto RUNNING 5:00
>> 0:02 1 None 2022-06-30T19:36:42
>> The job is running unless GrpTRESMins is under QOS support RawUsage .
>> Is there anything wrong with my control process that invalidates
1 None
> 2022-06-30T19:36:42
>
>
> The job is running unless GrpTRESMins is under QOS support RawUsage .
>
>
>
> Is there anything wrong with my control process that invalidates the result ?
>
>
> Thanks
>
> Gérard
>
> <http://www.cines.fr/
> Envoyé: Mercredi 29 Juin 2022 19:13:56
> Objet: Re: [slurm-users] GrpTRESMins and GrpTRESRaw usage
> Hi Miguel,
>>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 wi
SMins for an Account and not for a QOS, does SLURM handle to
>> sumpup these QOS RawUsage to control if the GrpTRESMins account limit is
>> reach
>> ?
>> Thanks again for your precious help.
>> Gérard
>> [ http://www.cines.fr/ ]
>>> De: "Miguel
nergy=0,node=216,billing=6929,fs/disk=0,vmem=0,pages=0
> cpu=17150 415766
>
>
> Something I forgot to do ?
>
>
> Best,
> Gérard
>
> Cordialement,
> Gérard Gil
>
> Département Calcul Intensif
> Centre Informatique National de l'En
http://www.cines.fr/ ]
> De: "Miguel Oliveira"
> À: "Slurm-users"
> Envoyé: Mardi 28 Juin 2022 17:23:18
> Objet: Re: [slurm-users] GrpTRESMins and GrpTRESRaw usage
> Hi Gérard,
> The way you are checking is against the association and as such it ought to be
&g
=216,billing=6929,fs/disk=0,vmem=0,pages=0
> cpu=17150 415766
>
>
> Something I forgot to do ?
>
>
> Best,
> Gérard
>
> Cordialement,
> Gérard Gil
>
> Département Calcul Intensif
> Centre Informatique National de l'Ens
er CEDEX 5
FRANCE
tel : (334) 67 14 14 14
fax : (334) 67 52 37 63
web : [ http://www.cines.fr/ | http://www.cines.fr ]
> De: "Gérard Gil"
> À: "Slurm-users"
> Cc: "slurm-users"
> Envoyé: Vendredi 24 Juin 2022 14:52:12
> Objet: Re: [slurm-users] Gr
sers"
> Envoyé: Vendredi 24 Juin 2022 14:07:16
> Objet: Re: [slurm-users] GrpTRESMins and GrpTRESRaw usage
> Hi Gérard,
>
> I believe so. All our accounts correspond to one project and all have an
> associated QoS with NoDecay and DenyOnLimit. This is enough to restrict usa
Hi Bjørn-Helge,
> On 24 Jun 2022, at 12:58, Bjørn-Helge Mevik wrote:
>
> Miguel Oliveira writes:
>
>> Hi Bjørn-Helge,
>>
>> Long time!
>
> Hi Miguel! Yes, definitely a long time! :D
Indeed!
>
>> Why not? You can have multiple QoSs and you have other techniques to change
>> priorities accor
Hi Gérard,
I believe so. All our accounts correspond to one project and all have an
associated QoS with NoDecay and DenyOnLimit. This is enough to restrict usage
on each individual project.
You only need these flags on the QoS. The association will carry on as usual
and fairshare will not be i
Miguel Oliveira writes:
> Hi Bjørn-Helge,
>
> Long time!
Hi Miguel! Yes, definitely a long time! :D
> Why not? You can have multiple QoSs and you have other techniques to change
> priorities according to your policies.
A job can only run in a single QoS, so if you submit a job with "sbatch
ith NoDecay ?"
Thanks
Best,
Gérard
- Mail original -
> De: "Miguel Oliveira"
> À: "Slurm-users"
> Cc: "slurm-users"
> Envoyé: Vendredi 24 Juin 2022 13:09:47
> Objet: Re: [slurm-users] GrpTRESMins and GrpTRESRaw usage
> Hi Bjørn-Hel
Hi Bjørn-Helge,
Long time!
Why not? You can have multiple QoSs and you have other techniques to change
priorities according to your policies.
Best,
MAO
> On 24 Jun 2022, at 11:53, Bjørn-Helge Mevik wrote:
>
> Miguel Oliveira writes:
>
>> It is not exactly true that you have no solution to
Miguel Oliveira writes:
> It is not exactly true that you have no solution to limit projects. If
> you implement each project as an account then you can create an
> account qos with the NoDecay flags.
> This will not affect associations so priority and fair share are not impacted.
Yes, that will
rpTRESMins limit?
Thanks
Regards,
Gérard
> De: "Miguel Oliveira"
> À: "Slurm-users"
> Cc: "slurm-users"
> Envoyé: Jeudi 23 Juin 2022 18:42:28
> Objet: Re: [slurm-users] GrpTRESMins and GrpTRESRaw usage
> Hi Gérard,
> It is not exa
Hi Ole,
Your script is a nice piece of scripting but I think you missed the point, if I
read your script correctly!
You read limits with:
scontrol -o show assoc_mgr users=$username $selectedaccount flags=Assoc
In our case the limits are declared in a QoS and not in the association and
hence wi
On 23-06-2022 19:19, Miguel Oliveira wrote:
We use a python wrapper to do this but the basic command to retrieved
account minutes is:
'scontrol -o show assoc_mgr | grep "^QOS='+account+’"'
You then have to parse the output for "GrpTRESMins=“. The output will be
two numbers. The first is the l
feature.
Thanks a lot.
Regards,
Gérard
<http://www.cines.fr/>
____________
De: "Bjørn-Helge Mevik"
À: slurm-us...@schedmd.com
Envoyé: Jeudi 23 Juin 2022 12:39:27
Objet: Re: [slurm-users] GrpTRESMins and GrpTRESRaw u
ESMins can't be used
> as we want.
>
> Setting the NoDecay flag to a QOS could be an option but I suppose it also
> impact fairshare Multifactor Priority of all jobs using this QOS.
>
> This means I have no solution to limit a project as we want, unless schedMD
> changes its
.fr/>
De: "Bjørn-Helge Mevik"
À: slurm-us...@schedmd.com
Envoyé: Jeudi 23 Juin 2022 12:39:27
Objet: Re: [slurm-users] GrpTRESMins and GrpTRESRaw usage
Ole Holm Nielsen writes:
Hi Bjørn-Helge,
Hello,
want, unless schedMD
> changes its behavior or adds a new feature.
>
> Thanks a lot.
>
> Regards,
> Gérard
> <http://www.cines.fr/>
>
> De: "Bjørn-Helge Mevik"
> À: slurm-us...@schedmd.com
> Envoyé: Jeudi 23 Juin 2022 12:39:27
> Objet: R
rd
[ http://www.cines.fr/ ]
> De: "Bjørn-Helge Mevik"
> À: slurm-us...@schedmd.com
> Envoyé: Jeudi 23 Juin 2022 12:39:27
> Objet: Re: [slurm-users] GrpTRESMins and GrpTRESRaw usage
> Ole Holm Nielsen writes:
>> Hi Bjørn-Helge,
> Hello, Ole! :)
>> On 6/2
Ole Holm Nielsen writes:
> Hi Bjørn-Helge,
Hello, Ole! :)
> On 6/23/22 09:18, Bjørn-Helge Mevik wrote:
>
>> Slurm the same internal variables are used for fairshare calculations as
>> for GrpTRESMins (and similar), so when fair share priorities are in use,
>> slurm will reduce accumulated GrpTR
Hi Bjørn-Helge,
On 6/23/22 09:18, Bjørn-Helge Mevik wrote:
writes:
TRESRaw cpu is lower than before as I'm alone on the system an no other job was
submitted.
Any explanation of this ?
I'd guess you have turned on FairShare priorities. Unfortunately, in
Slurm the same internal variables ar
writes:
> TRESRaw cpu is lower than before as I'm alone on the system an no other job
> was submitted.
> Any explanation of this ?
I'd guess you have turned on FairShare priorities. Unfortunately, in
Slurm the same internal variables are used for fairshare calculations as
for GrpTRESMins (an
writes:
> I thought job's cpu TRESRaw = nb of reserved core X walltime (mn)
It is the "TRES billing cost" x walltime. What the TRES billing cost of
a job is depends on how you've set up the TRESBillingWeights on the
partitions, and whethery you've defined PriorityFlags=MAX_TRES or not.
--
Re
Hi,
new strange behaviour.
I'm using sshare command to get the current values of GrpTRESRaw and
GrpTRESMins.
> agil: toto@login1:~/TEST$ sshare -A myproject -u " " -o
> account,user,GrpTRESRaw%80,GrpTRESMins
> Account User GrpTRESRaw GrpTRESMins
> --
>
Hello,
I am using SLURM v 19.05 and I am trying to figure out how the cpu GrpTRESRaw
is calculated for a job.
I would like to use GrpTRESMins to limit a project to an allotted amount of
hours.
If the limitation process works as defined in the documentation my tests show
some strange results
30 matches
Mail list logo
