[gpfsug-discuss] AFM negative file caching
david_johnson at brown.edu
david_johnson at brown.edu
Wed May 30 13:43:33 BST 2018
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 <peserocka at gmail.com> 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) <S.J.Thompson at bham.ac.uk> 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
More information about the gpfsug-discuss
mailing list