<div dir="ltr">Hi David,<br><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 23, 2023 at 10:50 AM David Laehnemann <<a href="mailto:david.laehnemann@hhu.de">david.laehnemann@hhu.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But from your comment I understand that handling these queries in<br>
batches would be less work for slurmdbd, right? So instead of querying<br>
each jobid with a separate database query, it would do one database<br>
query for the whole list? Is that really easier for the system, or<br>
would it end up doing a call for each jobid, anyway?<br></blockquote><div><br></div><div>From the perspective of avoiding RPC flood, it is much better to use a batch query. That said, if you have an extremely large number of jobs in the queue, you still wouldn't want to query the status too frequently.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

And just to be as clear as possible, a call to sacct would then look<br>
like this:<br>
sacct -X -P -n --format=JobIdRaw,State -j <jobid_1>,<jobid_2>,...<br></blockquote><div><br></div><div>That would be one way to do it, but I think there are other approaches that might be better. For example, there is no requirement for the job name to be unique. So if the snakemake pipeline has a configurable instance name="foo", and snakemake was configured to specify its own name as the job when submitting jobs (e.g. sbatch -J foo ...) then the query for all jobs in the pipeline is simply:</div><div><br></div><div>sacct --name=foo</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Because we can of course rewrite the respective code section, so any<br>
insight on how to do this job accounting more efficiently (and better<br>
tailored to how Slurm does things) is appreciated.<br></blockquote><div><br></div><div>I appreciate that you are interested in improving the integration to make it more performant. We are seeing an increase in meta-scheduler use at our site, so this is a worthwhile problem to tackle.</div><div><br></div><div>Thanks,</div><div><br></div><div>-Sean<br></div></div></div>