[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