Hi Sean, if you are using cgroups, another option might be to limit the I/O to disk(s) per job with the blkio controller https://lists.cs.wisc.edu/archive/htcondor-users/2017-August/msg00159.shtml Cheers, Thomas On 2017-11-01 10:45, Sean Crosby wrote: > > > On 24 October 2017 at 00:51, Greg Thain <gthain@xxxxxxxxxxx > <mailto:gthain@xxxxxxxxxxx>> wrote: > > On 10/23/2017 01:23 AM, Sean Crosby wrote: > > Hi all, > > We run jobs for the Belle experiment, and at the moment, their > jobs are very IO intensive. If say, on a 12 core node, if all 12 > cores are taken up by Belle jobs, the node suffers heavily from > IO problems. > > We'd like to limit the number of belle jobs on each node to be > (say e.g.) 4, but keep the other 8 slots to be open for other > user jobs. > > What's the easiest way to do this? > > > Machine custom resources are the best way to do this. On the > execute side, you can define how many resources that machine has, in > some arbitrary unit, like this: > > MACHINE_RESOURCE_Belle = 4 > > and in the job ad, the belle jobs should say > > Request_belle = 1 > > which means "only match to machines which have 1 or more belle > resources remaining, and consume 1 for the duration of my job". > > > This worked great. Many thanks for the tip. > > Cheers, > Sean >  > > > -greg > _______________________________________________ > > > > > -- > Sean Crosby > Research Computing > ARC Centre of Excellence for Particle Physics at the Terascale > School of Physics | University of Melbourne VIC 3010 Australia > > > _______________________________________________ > HTCondor-users mailing list > To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a > subject: Unsubscribe > You can also unsubscribe by visiting > https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users > > The archives can be found at: > https://lists.cs.wisc.edu/archive/htcondor-users/ >
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature