Come to think of it, there's a more elegant solution: 1. Enforce resource sharing via the SHARED=FORCE: 4 , that being the number of jobs that can run per CPU on that partition. The setting is partition specific. 2. Enable consumable resources tracking and allocation with CR_CPU_Memory . See the slurm config tool for more details on this. 3. Ensure that MaxMemPerCPU and MinMemPerCPU are defined. 4.Problem solved
On Jan 5, 2016 3:16 AM, Bruce Roberts <schedulerk...@gmail.com> wrote: Why? As Moe pointed out Slurm can do what he is asking. Slurm is a quite sophisticated scheduler/workload manager, it doesn't just manage resources anymore ;). On 01/04/16 15:52, Dennis Mungai wrote: Hello there, You may want to look into a scheduling system such as Maui or Moab. On Jan 5, 2016 2:14 AM, "GOLPAYEGANI, NAVID (GSFC-6190)" <navid.golpayeg...@nasa.gov><mailto:navid.golpayeg...@nasa.gov> wrote: Hi, SLURM newbie here. Anybody have suggestions on how to do the scheduling for a SLURM cluster for web submissions? We take orders from a webpage and submit them as a single account to SLURM. We want to avoid having a condition where web user2 single job has to wait behind web user1's hundreds jobs. What kind of scheduling method and/or job submission method would you guys recommend to use so that ideally a single web user can use as many available nodes as possible when nobody else is using them but can't (significantly) delay another web user's job. Thank you, Navid ______________________________________________________________________ This e-mail contains information which is confidential. It is intended only for the use of the named recipient. If you have received this e-mail in error, please let us know by replying to the sender, and immediately delete it from your system. Please note, that in these circumstances, the use, disclosure, distribution or copying of this information is strictly prohibited. KEMRI-Wellcome Trust Programme cannot accept any responsibility for the accuracy or completeness of this message as it has been transmitted over a public network. Although the Programme has taken reasonable precautions to ensure no viruses are present in emails, it cannot accept responsibility for any loss or damage arising from the use of the email or attachments. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of KEMRI-Wellcome Trust Programme. ______________________________________________________________________ ______________________________________________________________________ This e-mail contains information which is confidential. It is intended only for the use of the named recipient. If you have received this e-mail in error, please let us know by replying to the sender, and immediately delete it from your system. Please note, that in these circumstances, the use, disclosure, distribution or copying of this information is strictly prohibited. KEMRI-Wellcome Trust Programme cannot accept any responsibility for the accuracy or completeness of this message as it has been transmitted over a public network. Although the Programme has taken reasonable precautions to ensure no viruses are present in emails, it cannot accept responsibility for any loss or damage arising from the use of the email or attachments. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of KEMRI-Wellcome Trust Programme. ______________________________________________________________________
