Another possible workaround would be to add wrappers for these apps and only add the AFM based gpfs directory to the LD_LIBARY_PATH when about to launch the app.
-- ddj Dave Johnson > On May 30, 2018, at 8:26 AM, Peter Serocka <[email protected]> wrote: > > As a quick means, why not adding /usr/lib64 at the beginning of > LD_LIBRARY_PATH? > > (Not to get started on using LD_LIBRARY_PATH in the first place…) > > > — Peter > >> On 2018 May 30 Wed, at 13:52, Simon Thompson (IT Research Support) >> <[email protected]> wrote: >> >> Hi All, >> >> We have a file-set which is an AFM fileset and contains installed software. >> >> We’ve been experiencing some performance issues with workloads when this is >> running and think this is down to LD_LIBRARY_PATH being set to the software >> installed in the AFM cache, e.g. >> >> /gpfs/apps/somesoftware/v1.2/lib >> >> Subsequently when you run (e.g.) “who” on the system, LD_LIBRARY_PATH is >> being searched for e.g. libnss_ldap, which is in /usr/lib64. We’re assuming >> that AFM is checking with home each time the directory is processed (and >> other sub directories like lib/tls) and that each time AFM is checking for >> the file’s existence at home. Is there a way to change the negative cache at >> all on AFM for this one file-set? (e.g as you might with NFS). The file-set >> only has applications so changes are pretty rare and so a 10 min or so check >> would be fine with me. >> >> Thanks >> >> Simon >> >> _______________________________________________ >> gpfsug-discuss mailing list >> gpfsug-discuss at spectrumscale.org >> http://gpfsug.org/mailman/listinfo/gpfsug-discuss > > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at spectrumscale.org > http://gpfsug.org/mailman/listinfo/gpfsug-discuss _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
