I don't think fairshare use is updated until jobs finish... On Fri, Aug 9, 2024 at 5:59 PM Drucker, Daniel via slurm-users < slurm-users@lists.schedmd.com> wrote:
> Hi Paul from over at mclean.harvard.edu! > > I have never added *any* users using sacctmgr - I've always just had > everyone I guess automatically join the default account, *mic*. Are you > saying that is what is causing my problem? > > I'm confused I guess because I would have expected that *within* an > account - even if there is only one - users would get their 'fair share' of > resources, rather than just defaulting to FIFO or something. But that > doesn't seem to be the case. > > I do not want any particular user to start out with more priority than any > other particular user - I just want to make sure that if user A submits a > million jobs at noon, and user B submits one job at 12:01, user B doesn't > have to wait until those million jobs finish. > > Daniel > > > On Aug 9, 2024, at 5:47 PM, Paul Raines <rai...@nmr.mgh.harvard.edu> > wrote: > > > This depends on how you have assigned fairshare in sacctmgr when creating > the accounts and users. At our site we want fairshare only on accounts > and not users, just like you are seeing, so we create accounts with > > sacctmgr -i add account $acct Description="$descr" \ > fairshare=200 GrpJobsAccrue=8 > > and users with > > sacctmgr -i add user "$u" account=$acct fairshare=parent > > If you want users to have their own independent fairshare, you > do not use fairshare=parent but assign a real number. > > -- Paul Raines (http://help.nmr.mgh.harvard.edu) > > > > On Fri, 9 Aug 2024 5:20pm, Drucker, Daniel via slurm-users wrote: > > External Email - Use Caution > I got the opposite result. When I submitted a job as bsmith, they got a > lower priority (the number was smaller) than the job submitted as csmith. > > bsmith (who has never submitted a job before) got a priority of 98387 > (which is 10000 times the 0.983871 FairShare), whereas csmith (who is > already running a huge number of jobs and has been for days now) got a > priority of 103749. > > > > On Aug 9, 2024, at 5:11 PM, Renfro, Michael <ren...@tntech.edu> wrote: > > > External Email - Use Caution > > The format has changed a bit, since none of our RawShares column is > ‘parent’. > > But you can test this to be certain. > > If your cluster already has jobs pending, have bsmith (who has zero usage) > and csmith (who has a lot of usage, relatively) each submit several jobs > into the pending queue. Alternatively, have bsmith and csmith submit jobs > with larger resource requests: jobs that are large enough to automatically > go into a pending state due to lack of resources. Those might be jobs that > request the whole cluster, even. > > bsmith’s jobs should get a higher priority as seen from sprio, and > bsmith’s jobs should start earlier than csmith’s. > The information in this e-mail is intended only for the person to whom it > is addressed. If you believe this e-mail was sent to you in error and the > e-mail contains patient information, please contact the Mass General > Brigham Compliance HelpLine at > https://www.massgeneralbrigham.org/complianceline < > https://www.massgeneralbrigham.org/complianceline> . > Please note that this e-mail is not secure (encrypted). If you do not > wish to continue communication over unencrypted e-mail, please notify the > sender of this message immediately. Continuing to send or respond to > e-mail after receiving this message means you understand and accept this > risk and wish to continue to communicate over unencrypted e-mail. > > > The information in this e-mail is intended only for the person to whom it > is addressed. If you believe this e-mail was sent to you in error and the > e-mail contains patient information, please contact the Mass General > Brigham Compliance HelpLine at > https://www.massgeneralbrigham.org/complianceline . > > Please note that this e-mail is not secure (encrypted). If you do not > wish to continue communication over unencrypted e-mail, please notify the > sender of this message immediately. Continuing to send or respond to > e-mail after receiving this message means you understand and accept this > risk and wish to continue to communicate over unencrypted e-mail. > > -- > slurm-users mailing list -- slurm-users@lists.schedmd.com > To unsubscribe send an email to slurm-users-le...@lists.schedmd.com >
-- slurm-users mailing list -- slurm-users@lists.schedmd.com To unsubscribe send an email to slurm-users-le...@lists.schedmd.com
