Hi, Thanks for your suggestions. I tried the approach:
sacctmgr modify account <xxx> cluster=<yyy> set RawUsage=0 Of course it reset the Rawusage to 0, but after Firshare was auto-recalculated the statistic are still "historic" because the "Effective Usage" still reflects the historic usage, so the Fairshare is more/less the same than before. Additionally, something funny is that the RawUsage got some numbers (different to 0) when the statistics were recalculated. Any ideas to reset the whole thing completely? Daniel 2011/7/19 Danny Auble <[email protected]> > ** > > Along Don's sacctmgr suggestion you should be able to specify "root" as the > account which will flush the entire fairshare usage. I would avoid using the > first method unless all else fails. > > > On a side note, using the sacctmgr method it appears you need to specify > the cluster as well (i.e. sacctmgr modify account <xxx> cluster=<yyy> set > RawUsage=0). I'll see about getting that to default to the local cluster in > 2.3. > > > Danny > > > On Monday July 18 2011 8:15:43 AM you wrote: > > > Daniel, > > > > > > The brute force approach to zero out all usage would be to stop the > slurmctld, remove the StateSaveLocation/assoc_usage and assoc_usage.old > files, and restart the slurmctld. > > > > > > You can reset the usage on a specific account using "sacctmgr modify > account <xxx> set RawUsage=0". > > > > > > Don > > > > > > From: [email protected] [mailto: > [email protected]] On Behalf Of Daniel Adriano Silva M > > > Sent: Monday, July 18, 2011 12:08 AM > > > To: slurm-dev > > > Subject: [slurm-dev] How to completely reset the Fairshare stats? > > > > > > Hi, > > > > > > I have a problem here! Previously we were using the multifactor plugin by > some months but just based in the QOS (i.e. I put 0 to all the other > factors). But now it become evident tat we really need the fairshare to keep > a better balance of the resources allocation, so two days ago I activated > the other multifactors like this: > > > > > > > > > #MultiFactorPriority for Jobs > > > PriorityType=priority/multifactor > > > PriorityDecayHalfLife=7 > > > PriorityCalcPeriod=5 > > > PriorityFavorSmall=NO > > > PriorityMaxAge=7-0 > > > PriorityWeightAge=1000 > > > PriorityWeightFairshare=5000 > > > PriorityWeightJobSize=1000 > > > PriorityWeightPartition=1000 > > > PriorityWeightQOS=5000 > > > PriorityUsageResetPeriod=NONE > > > > > > Now the problem is the next, as the history of the database is OLD the > users got a very small Fairshare factor (near to 0). I tried the reset trick > ( PriorityUsageResetPeriod=NOW) to reset the stats, it worked, but as soon > as I returned it to "NONE" and restarted the controller the sats went again > near to 0. So the question is, how to really reset the fairshare thing? This > in order to give a "fresh start" to the users. > > > > > > JOBID PRIORITY AGE FAIRSHARE JOBSIZE PARTITION QOS > > > 14057 6319 256 0 63 1000 5000 > > > 14064 6191 168 2 21 1000 5000 > > > 14065 6191 168 2 21 1000 5000 > > > 14066 6191 168 2 21 1000 5000 > > > 14067 6191 168 2 21 1000 5000 > > > 14068 6191 168 2 21 1000 5000 > > > 14069 6191 168 2 21 1000 5000 > > > 14070 6191 168 2 21 1000 5000 > > > 14071 6191 168 2 21 1000 5000 > > > 14072 6191 168 2 21 1000 5000 > > > 14093 6141 120 0 21 1000 5000 > > > 14094 6141 119 0 21 1000 5000 > > > 14105 6085 21 0 63 1000 5000 > > > 14106 6085 21 0 63 1000 5000 > > > 14107 6085 21 0 63 1000 5000 > > > 14108 6085 21 0 63 1000 5000 > > > 14114 6061 6 12 42 1000 5000 > > > 14115 6061 6 12 42 1000 5000 > > > 14116 6061 6 12 42 1000 5000 > > > > > > > > > BTW. SLURM is fantastic. Good Job! > > > > > > Thanks, > > > Daniel >
