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
