Is "prologue script" a Grid Engine concept? What I am doing right now is running a script that submits jobs to SGE to set up a list of environment servers on a list of hosts. Each job sets up one environment on one host...these jobs occupy a slot unfortunately and limit the number of simulations I can run on each host. In fact if the number of environments running equals the number of slots/CPUs, then I cannot run ANY simulations. How does a "prologe script" get around this?
On Tue, Apr 3, 2012 at 12:03 PM, Jesse Becker <[email protected]>wrote: > How about using a prologue script to setup your environment before > running the job? > > > On Tue, Apr 03, 2012 at 12:56:47PM -0400, Earl Lazarus wrote: > >> Our environment is a linux cluster with 4 CPUs per machine. We are >> changing the architecture of a Monte Carlo simulation that we routinely run >> via Grid Engine. In the new paradigm, each instance will need to >> communicate via sockets with an "Environment Server" running on the host >> where the sim executes. We need to kick off these environment servers >> prior to submitting the simulation jobs. These servers are basically >> inactive unless queried by one of the sims. We also want to allow the >> environment servers to run possibly for days or weeks at a time as they are >> low impact. >> >> However, what I really want to do is kick off an environment server on a >> host and not have it count against the "slot count" for that host. There >> will be instances where I might need 4 different environment servers >> running on each host. Unfortunately that would occupy all of my slots and >> NONE of my simulations would ever run!! >> >> I have seen the concept of "Parallel Environments" in the SGE User >> Manual, but the explanation is pretty much worthless. >> >> Bottom line...I need to pre-position some executables on each host >> without consuming slots. Note that I tried to kick them off in a script >> of the form: >> >> sppe & >> exit >> >> but Grid Engine monitors jobs placed in the background and kills them! >> >> The possibility of avoiding Grid Engine entirely and kicking them off >> with rsh/ssh is something we want to avoid. >> >> earl >> > > ______________________________**_________________ >> users mailing list >> [email protected] >> https://gridengine.org/**mailman/listinfo/users<https://gridengine.org/mailman/listinfo/users> >> > > > -- > Jesse Becker > NHGRI Linux support (Digicon Contractor) > :(){ :&:};: >
_______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
