That's essentially what I've been doing-- a daily 'sacct' that dumps a json file, and then I dig through the json files. I'm basically doing the same thing that sreport is doing. Given the enormous amount of machinery in Slurm for handling rollups, it seems bizarre that the whole thing is made useless because of a seemingly-odd decision to treat certain pending jobs as if they were running for accounting purposes.
On 3/4/24, 12:38 PM, "Brian Andrus via slurm-users" <slurm-users@lists.schedmd.com <mailto:slurm-users@lists.schedmd.com>> wrote: Chip, I use 'sacct' rather than sreport and get individual job data. That is ingested into a db and PowerBI, which can then aggregate as needed. sreport is pretty general and likely not the best for accurate chargeback data. Brian Andrus On 3/4/2024 6:09 AM, Chip Seraphine via slurm-users wrote: > Hello, > > I am attempting to implement a billback model and finding myself stymied by > the way that sreport handles job arrays. Basically, when a user submits a > large array, their usage includes time that jobs in the back of the array > spend waiting their turn. (My #1 user in “sreport user topusage” shows more > “used” cpu*minutes than the cluster physically _has_ during that interval.) > However, jobs that are idle pending resources are simply regarded as pending; > as a result, a “polite” user who submits an array of 1000 jobs running N at a > time is penalized over a user who just dumps 1000 loose jobs into the queue. > This incentives my users to do exactly what I do not want! > > Has anyone tried to bill their users based on the results of sreport? If so, > how did you work around this problem? What did you use to determine the # of > CPU*Minutes that a user actually allocated on during a given interval? > > -- > > Chip Seraphine > Grid Operations > For support please use help-grid in email or slack. > This e-mail and any attachments may contain information that is confidential > and proprietary and otherwise protected from disclosure. If you are not the > intended recipient of this e-mail, do not read, duplicate or redistribute it > by any means. Please immediately delete it and any attachments and notify the > sender that you have received it by mistake. Unintended recipients are > prohibited from taking action on the basis of information in this e-mail or > any attachments. The DRW Companies make no representations that this e-mail > or any attachments are free of computer viruses or other defects. > -- slurm-users mailing list -- slurm-users@lists.schedmd.com <mailto:slurm-users@lists.schedmd.com> To unsubscribe send an email to slurm-users-le...@lists.schedmd.com <mailto:slurm-users-le...@lists.schedmd.com> -- slurm-users mailing list -- slurm-users@lists.schedmd.com To unsubscribe send an email to slurm-users-le...@lists.schedmd.com
