how do you run your batch jobs?

[Scott R. Presnell]

jdh at bu-pub.bu.edu (Jason Heirtzler) writes:

>At BU we have our jobs on the SGIs split into two categories: long
>running (non-interactive) batch jobs and interactive jobs, typically
>whomever is sitting at the console.

>What we'd like to do is reduce the batch jobs to having the lowest
>impact on the interactive jobs.  It looks like one possible way to
>do this is to start cron with `runon 3 cron' and maybe changing the
>queuedefs file to further reduce the batch processes priority.  This
>would, unfortunately, nullify any parallelism in the batch task.

>If you have a system for handling batch jobs that you think is useful,
>I'd be interested in hearing from you.

I have written a batch job handler that seems to work for us.  Some of the
things it can do...
	1) Start and stop at various times of the day.
	2) Start and stop at varying loads.
	3) Start and stop based on whether or not someone has logged
		into the console. (interactive tasks have a definite
		priority at our site).

	(start and stop by sending SIGCONT and SIGSTOP to entire process
		groups)

	4) Run jobs with different nices *and* different n-pri's
	
	5) There is message logging and accounting as well.

The interface looks something like BSD lpr: there is a /etc/batchcap. and
the programs are:
	batch, baq, barm, bac (and batchd for the daemon).

I haven't "beta" tested it with anyone, and I have no idea what it will do
on a multiprocessor machine as we don't have one (this was developed on a
PI).  To be honest, I'm still fixing the occasional bug.  But it's used
almost constantly, and the daemon basically never goes down.  I'm still
adding features and making it more robust.

If your interested, drop me a line.

	- Scott
--
Scott Presnell				        +1 (415) 476-9890
Pharm. Chem., S-926				Internet: srp at cgl.ucsf.edu
University of California			UUCP: ...ucbvax!ucsfcgl!srp
San Francisco, CA. 94143-0446			Bitnet: srp at ucsfcgl.bitnet