[gpfsug-discuss] gpfs performance monitoring
Salvatore Di Nardo
sdinardo at ebi.ac.uk
Thu Sep 4 11:58:51 BST 2014
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, service at metamodul.com 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20140904/68ff9b7a/attachment-0003.htm>
More information about the gpfsug-discuss
mailing list