Yes, well, in that case, it should work as you desire, modulo your slurm.conf settings. What are the relevant lines in yours?
On Fri, Aug 9, 2024 at 6:09 PM Drucker, Daniel <ddruc...@mclean.harvard.edu> wrote: > Er, user B has never. > > On Aug 9, 2024, at 6:08 PM, Daniel M. Drucker <ddruc...@mclean.harvard.edu> > wrote: > > Well, let's say user A has completed a million jobs in the last few days > as well, and user A has never submitted any before. > > On Aug 9, 2024, at 6:03 PM, Fulcomer, Samuel <samuel_fulco...@brown.edu> > wrote: > > External Email - Use Caution > > 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 >> > > > 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
