[GE users] Getting rid of LD_LIBRARY_PATH

John Saalwaechter bababooey182 at yahoo.com
Fri Oct 15 21:30:27 BST 2004


Actually, SGE jobs automatically get LD_LIBRARY_PATH (or whatever
variable the OS uses) set for them, independent of sourcing the
settings.(c)sh file.  In SGE 5.3, this happens in
source/daemons/execd/exec_job.c in the set_sharedlib_path() function.
So every grid job is running with the SGE library path at the
head of LD_LIBRARY_PATH.

When 100s of cpus are running an SGE array job that is a shell script
calling lots of other executables, the unnecessary ld searching
generates a substantial network load against the NFS-shared
$SGE_ROOT.  Enough network load, in fact, to cause lots of errors
and rescheduling because the qmaster has trouble getting its own
NFS traffic through to $SGE_ROOT.  We ended up solving this problem
by running a private link between the qmaster and the NAS device
holding $SGE_ROOT, and we instantly saw improved SGE reliability.
We'd still like to eliminate all the needless traffic still flying
around the network related to LD_LIBRARY_PATH.

--- Reuti <reuti at staff.uni-marburg.de> wrote:

> Going back to the root of this thread: The sourced settings file on the 
> exec hosts.
> 
> This is not necessary to run the job. If there is only one point to 
> define whether it's sourced, an if-then could be used depending on the node.
> 
> I never source the settings in my clusters on the exec hosts (only if I 
> have to execute a SGE command).
> 
> Cheers - Reuti



		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list