Summary: | Add a per-user limit analogous to grptresmins | ||
---|---|---|---|
Product: | Slurm | Reporter: | Marshall Garey <marshall> |
Component: | Database | Assignee: | Unassigned Developer <dev-unassigned> |
Status: | OPEN --- | QA Contact: | |
Severity: | 5 - Enhancement | ||
Priority: | --- | CC: | fordste5, robert.yelle |
Version: | 18.08.x | ||
Hardware: | Linux | ||
OS: | Linux | ||
Site: | MSU | Alineos Sites: | --- |
Atos/Eviden Sites: | --- | Confidential Site: | --- |
Coreweave sites: | --- | Cray Sites: | --- |
DS9 clusters: | --- | HPCnow Sites: | --- |
HPE Sites: | --- | IBM Sites: | --- |
NOAA SIte: | --- | NoveTech Sites: | --- |
Nvidia HWinf-CS Sites: | --- | OCF Sites: | --- |
Recursion Pharma Sites: | --- | SFW Sites: | --- |
SNIC sites: | --- | Tzag Elita Sites: | --- |
Linux Distro: | --- | Machine Name: | |
CLE Version: | Version Fixed: | ||
Target Release: | --- | DevPrio: | --- |
Emory-Cloud Sites: | --- |
Description
Marshall Garey
2018-06-28 15:13:11 MDT
Steve, adding you to CC again. Feel free to take yourself off of or add anyone else to CC. If I remember, you want to limit each user in an association or QOS to a certain number of CPU-minutes in total - something you could reset user's usage for each year. Is that correct? This doesn't exist currently. We only have the GrpTresMins limit. I'm actually going to change the site to MSU. And I'm setting this to sev-4 for now so Tim will see it, though this is an enhancement request. Marshall, that is correct. We want this limit to apply to each user individually. It looks like setting the GrpTRESMins setting on account/user associations will do what we want, e.g `sacctmgr mod user foo where account=general set GrpTRESMins=cpu=100`. This may also work when set on a user/QOS association though I have not tested it. Having a GrpTRESMinsPerUser setting would be helpful since we could set limits on just the account instead of each user/account association. For now, we can set GrpTRESMins on account/user associations when we add users to the accounting database. To enforce these limits and reset them every year, we should set AccountingStorgeEnforce=limits, PriorityDecayHalfLife=0, and PriorityUsageResetPeriod=YEARLY, is that correct? (In reply to Steve Ford from comment #2) > To enforce these limits and reset them every year, we should set > AccountingStorgeEnforce=limits, PriorityDecayHalfLife=0, and > PriorityUsageResetPeriod=YEARLY, is that correct? Yes, though that would apply globally for every user, not just the users with the grptresmins limit. It also means you won't get usage decay, so a user's usage several months ago (assuming it's still within the same year period) would still count against them for fairshare. If that's a concern, you might want to set PriorityWeightFairshare relatively low compared to the other PriorityWeight parameters. If for any reason you need to manually reset a user's usage, an admin can do so with sacctmgr: $ sacctmgr mod user testuser2 account=testacct cluster=byu set rawusage=0 Would you like to reset usage? (You have 30 seconds to decide) (N/y): n Changes Discarded Changing back to a sev-5 and changing asignee to dev-unassigned. I'd like to do this, but I don't think I'm getting this done in time for 18.08. It's also not one of the undocumented limits that exist in the database but don't do anything yet, so a new one needs to be added in. *** Ticket 13558 has been marked as a duplicate of this ticket. *** |