[Swift-devel] Try coaster on BG/P ?
Ben Clifford
benc at hawaga.org.uk
Thu Jun 19 18:45:22 CDT 2008
more notes on running this on a normal site:
Set the jobThrottle parameter for a site based on the mechanism used to
submit coasters - that is, for a site that is submitting through GRAM2,
set the throttle to 0.2, which will limit you to 20 jobs at once, and
likely cause just under 20 coaster workers to run. When GRAM4 works,
should be able to use a jobThrottle of 4 and get 400 workers to run (at
least as far as the coaster-submission side of things).
I have done any tests (though Mihael might have) about how many coaster
workers can run sensibly at once - most of my testing has been poking
round at the low end of things.
When you start running jobs, the timings will look a bit different -
you'll see a much longer delay than usual when the first job goes into
execute state, as this is when the coaster master starts up on the remote
site and submits a worker into the queue But once workers start actually
executing, subsequent job executions will be faster (in as much as there
should be no GRAM latency and no LRM latency).
The basic pattern is as long as there are more jobs ready to be run than
there are workers, then more workers will be started (but will be subject
to LRM delays in starting up).
--
More information about the Swift-devel
mailing list