Karl Forner wrote:
> Phil Ehrens wrote:
>
> >Don't create a seperate lam user for each user, but DO create
> >more than one. If one account suffices when no failures occur,
> >and if failures costs you 50% of your duty cycle, have two users,
> >and so forth, using them in round-robin fashion. That's what we
> >do, and we achieve job rates of > 2000 jobs per hour over weeks
> >of running.
> >
> >
> I tried once a workaround like this, using the session prefix feature,
> but sometimes the lamboot command hung, and it became hard to debug and
> maintain.
I am not using the session prefix feature, and this is not a workaround.
This is the normal way of operating a high performance batch processing
environment... let the operating system figure out what belongs to which
job and you don't have to.
I never experience lamboot hangs, and, as I say, we are getting continuous
job throughput of >2000 jobs/hr with typically 6-8 users active, so that
is as many users as you would ever have to create in all likelihood.
> If I has to spend so more time, I'd prefer improving LAM than my private
> software, kind of deserved contribution :-)
Noble, but lam is not a batch processing environment.
--
Phil Ehrens <pehrens_at_[hidden]>| Fun stuff:
The LIGO Laboratory, MS 18-34 | http://www.ralphmag.org
California Institute of Technology | http://www.yellow5.com
1200 East California Blvd. | http://www.total.net/~fishnet/
Pasadena, CA 91125 USA | http://slashdot.org
Phone:(626)395-8518 Fax:(626)793-9744 | http://kame56.homepage.com
|
