Little clarification, the filsystemn its not always slow. It happens
that became very slow with particular users jobs in the farm. Maybe its
just an indication thant we have huge ammount of metadata requestes,
that's why i want to be able to monitor them
On 04/09/14 11:05, [email protected] wrote:
> , any "ls" could take ages.
Check if you large directories either with many files or simply large.
it happens that the files are very large ( over 100G), but there
usually ther are no many files.
Verify if you have NFS exported GPFS.
No NFS
Verify that your cache settings on the clients are large enough (
maxStatCache , maxFilesToCache , sharedMemLimit )
will look at them, but i'm not sure that the best number will be on the
client. Obviously i cannot use all the memory of the client because
those blients are meant to run jobs....
Verify that you have dedicated metadata luns ( metadataOnly )
Yes, we have dedicate vdisks for metadata, but they are in the same
declustered arrays/recoverygroups, so they whare the same spindles
Reference:
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/General%20Parallel%20File%20System%20%28GPFS%29/page/Tuning%20Parameters
Note:
If possible monitor your metadata luns on the storage directly.
that’s exactly than I'm trying to do !!!! :-D
hth
Hajo
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at gpfsug.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at gpfsug.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
