Hi, Just to follow up this, at the end what I did was to recreate the sacctmgr accounts that reset everything to 0 again. Thanks for your suggestions.
Regards, Daniel 2011/7/20 Daniel Adriano Silva M <[email protected]> > 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 >> > >
