Thank you for the response! I have given those parameters a shot and will monitor the queue.
These parameters would really only impact backfill with respect to job time limits, correct? Based on what I have read, I was under the impression that the main scheduler and the backfill scheduler were partition independent. Meaning that if I have a large number of jobs queued for a single partition, another partition which has no jobs running would be seen as free by the scheduler and should not queue jobs with respect to the filled partition. Do you know if I’m mistaken? Jason Dana JHUAPL REDD/RA2 Senior Systems Administrator/Software Engineer jason.d...@jhuapl.edu<mailto:jason.d...@jhuapl.edu> 240-564-1045 (w) Need Support from REDD? You can enter a ticket using the new REDD Help Desk Portal (https://help.rcs.jhuapl.edu/servicedesk) if you have an active account or e-mail redd-h...@outermail.jhuapl.edu<mailto:redd-h...@outermail.jhuapl.edu>. From: slurm-users <slurm-users-boun...@lists.schedmd.com> on behalf of "Renfro, Michael" <ren...@tntech.edu> Reply-To: Slurm User Community List <slurm-users@lists.schedmd.com> Date: Friday, June 11, 2021 at 2:16 PM To: Slurm User Community List <slurm-users@lists.schedmd.com>, "slurm-us...@schedmd.com" <slurm-us...@schedmd.com> Subject: [EXT] Re: [slurm-users] Slurm Scheduler Help APL external email warning: Verify sender slurm-users-boun...@lists.schedmd.com before clicking links or attachments Not sure it would work out to 60k queued jobs, but we're using: SchedulerParameters=bf_window=43200,bf_resolution=2160,bf_max_job_user=80,bf_continue,default_queue_depth=200 in our setup. bf_window is driven by our 30-day max job time, bf_resolution is at 5% of that time, and the other values are just what we landed on. This did manage to address some backfill issues we had in previous years. From: slurm-users <slurm-users-boun...@lists.schedmd.com> on behalf of Dana, Jason T. <jason.d...@jhuapl.edu> Date: Friday, June 11, 2021 at 12:27 PM To: slurm-us...@schedmd.com <slurm-us...@schedmd.com> Subject: [slurm-users] Slurm Scheduler Help External Email Warning This email originated from outside the university. Please use caution when opening attachments, clicking links, or responding to requests. ________________________________ Hello, I currently manage a small cluster separated into 4 partitions. I am experiencing unexpected behavior with the scheduler when the queue has been flooded with a large number of jobs by a single user (around 60000) to a single partition. We have each user bound to a global grptres CPU limit. Once this user reaches their CPU limit the jobs are queued with reason “AssocGroupCpuLimit” but after a few hundred or so of the jobs it seems to switch to “Priority”. The issue is that once this switch occurs it appears to also impact all other partitions. Currently if any job is submitted to any of the partitions, regardless of resources available, they are all queued by the scheduler with the reason of “Priority”. We had the scheduler initially configured for backfill but have also tried switching to builtin and it did not seem to make a difference. I tried increasing the default_queue_depth to 100000 and it didn’t seem to help. The scheduler log is also unhelpful as it simply lists the accounting-limited jobs and never mentions the “Priority” queued jobs: sched: [2021-06-11T13:21:53.993] JobId=495780 delayed for accounting policy sched: [2021-06-11T13:21:53.997] JobId=495781 delayed for accounting policy sched: [2021-06-11T13:21:54.001] JobId=495782 delayed for accounting policy sched: [2021-06-11T13:21:54.005] JobId=495783 delayed for accounting policy sched: [2021-06-11T13:21:54.005] loop taking too long, breaking out I’ve gone through all the documentation I’ve found on the scheduler and cannot seem to resolve this. I’m hoping I’m simply missing something. Any help would be great. Thank you! Jason
