<div dir="ltr">its not the only place used, but we see that most calls for attributes even from simplest ls requests are beyond what the StatCache provides, therefore my advice is always to disable maxStatCache by setting it to 0 and raise the maxFilestoCache limit to a higher than default as the memory is better spent there than wasted on StatCache, there is also waste by moving back and forth between StatCache and FileCache if you constantly need more that what the FileCache provides, so raising it and reduce StatCache to zero eliminates this overhead (even its just a few cpu cycles). <div>on LROC its essential as a LROC device can only keep data or Metadata for files it wants to hold any references if it has a StatCache object available, this means if your StatCache is set to 10000 and lets say you have 100000 files you want to cache in LROC this would never work as we throw the oldest out of LROC as soon as we try to cache nr 10001 as we have to reuse a StatCache Object to keep the reference to the data or metadata block stored in LROC . </div><div><br><div>Sven</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 21, 2016 at 12:48 PM Peter Childs <<a href="mailto:p.childs@qmul.ac.uk">p.childs@qmul.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So your saying maxStatCache should be raised on LROC enabled nodes only as its the only place under Linux its used and should be set low on non-LROC enabled nodes.<br class="gmail_msg">
<br class="gmail_msg">
Fine just good to know, nice and easy now with nodeclasses....<br class="gmail_msg">
<br class="gmail_msg">
Peter Childs<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
________________________________________<br class="gmail_msg">
From: <a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" class="gmail_msg" target="_blank">gpfsug-discuss-bounces@spectrumscale.org</a> <<a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" class="gmail_msg" target="_blank">gpfsug-discuss-bounces@spectrumscale.org</a>> on behalf of Sven Oehme <<a href="mailto:oehmes@gmail.com" class="gmail_msg" target="_blank">oehmes@gmail.com</a>><br class="gmail_msg">
Sent: Wednesday, December 21, 2016 11:37:46 AM<br class="gmail_msg">
To: gpfsug main discussion list<br class="gmail_msg">
Subject: Re: [gpfsug-discuss] LROC<br class="gmail_msg">
<br class="gmail_msg">
StatCache is not useful on Linux, that hasn't changed if you don't use LROC on the same node. LROC uses the compact object (StatCache) to store its pointer to the full file Object which is stored on the LROC device. so on a call for attributes that are not in the StatCache the object gets recalled from LROC and converted back into a full File Object, which is why you still need to have a reasonable maxFiles setting even you use LROC as you otherwise constantly move file infos in and out of LROC and put the device under heavy load.<br class="gmail_msg">
<br class="gmail_msg">
sven<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
On Wed, Dec 21, 2016 at 12:29 PM Peter Childs <<a href="mailto:p.childs@qmul.ac.uk" class="gmail_msg" target="_blank">p.childs@qmul.ac.uk</a><mailto:<a href="mailto:p.childs@qmul.ac.uk" class="gmail_msg" target="_blank">p.childs@qmul.ac.uk</a>>> wrote:<br class="gmail_msg">
My understanding was the maxStatCache was only used on AIX and should be set low on Linux, as raising it did't help and wasted resources. Are we saying that LROC now uses it and setting it low if you raise maxFilesToCache under linux is no longer the advice.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Peter Childs<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
________________________________________<br class="gmail_msg">
From: <a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" class="gmail_msg" target="_blank">gpfsug-discuss-bounces@spectrumscale.org</a><mailto:<a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" class="gmail_msg" target="_blank">gpfsug-discuss-bounces@spectrumscale.org</a>> <<a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" class="gmail_msg" target="_blank">gpfsug-discuss-bounces@spectrumscale.org</a><mailto:<a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" class="gmail_msg" target="_blank">gpfsug-discuss-bounces@spectrumscale.org</a>>> on behalf of Sven Oehme <<a href="mailto:oehmes@gmail.com" class="gmail_msg" target="_blank">oehmes@gmail.com</a><mailto:<a href="mailto:oehmes@gmail.com" class="gmail_msg" target="_blank">oehmes@gmail.com</a>>><br class="gmail_msg">
Sent: Wednesday, December 21, 2016 9:23:16 AM<br class="gmail_msg">
To: gpfsug main discussion list<br class="gmail_msg">
Subject: Re: [gpfsug-discuss] LROC<br class="gmail_msg">
<br class="gmail_msg">
Lroc only needs a StatCache object as it 'compacts' a full open File object (maxFilesToCache) to a StatCache Object when it moves the content to the LROC device.<br class="gmail_msg">
therefore the only thing you really need to increase is maxStatCache on the LROC node, but you still need maxFiles Objects, so leave that untouched and just increas maxStat<br class="gmail_msg">
<br class="gmail_msg">
Olaf's comment is important you need to make sure your manager nodes have enough memory to hold tokens for all the objects you want to cache, but if the memory is there and you have enough its well worth spend a lot of memory on it and bump maxStatCache to a high number. i have tested maxStatCache up to 16 million at some point per node, but if nodes with this large amount of inodes crash or you try to shut them down you have some delays , therefore i suggest you stay within a 1 or 2  million per node and see how well it does and also if you get a significant gain.<br class="gmail_msg">
i did help Bob to setup some monitoring for it so he can actually get comparable stats, i suggest you setup Zimon and enable the Lroc sensors to have real stats too , so you can see what benefits you get.<br class="gmail_msg">
<br class="gmail_msg">
Sven<br class="gmail_msg">
<br class="gmail_msg">
On Tue, Dec 20, 2016 at 8:13 PM Matt Weil <<a href="mailto:mweil@wustl.edu" class="gmail_msg" target="_blank">mweil@wustl.edu</a><mailto:<a href="mailto:mweil@wustl.edu" class="gmail_msg" target="_blank">mweil@wustl.edu</a>><mailto:<a href="mailto:mweil@wustl.edu" class="gmail_msg" target="_blank">mweil@wustl.edu</a><mailto:<a href="mailto:mweil@wustl.edu" class="gmail_msg" target="_blank">mweil@wustl.edu</a>>>> wrote:<br class="gmail_msg">
<br class="gmail_msg">
as many as possible and both<br class="gmail_msg">
<br class="gmail_msg">
have maxFilesToCache 128000<br class="gmail_msg">
<br class="gmail_msg">
and maxStatCache 40000<br class="gmail_msg">
<br class="gmail_msg">
do these effect what sits on the LROC as well?  Are those to small? 1million seemed excessive.<br class="gmail_msg">
<br class="gmail_msg">
On 12/20/16 11:03 AM, Sven Oehme wrote:<br class="gmail_msg">
how much files do you want to cache ?<br class="gmail_msg">
and do you only want to cache metadata or also data associated to the files ?<br class="gmail_msg">
<br class="gmail_msg">
sven<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
On Tue, Dec 20, 2016 at 5:35 PM Matt Weil <<a href="mailto:mweil@wustl.edu" class="gmail_msg" target="_blank">mweil@wustl.edu</a><mailto:<a href="mailto:mweil@wustl.edu" class="gmail_msg" target="_blank">mweil@wustl.edu</a>><mailto:<a href="mailto:mweil@wustl.edu" class="gmail_msg" target="_blank">mweil@wustl.edu</a><mailto:<a href="mailto:mweil@wustl.edu" class="gmail_msg" target="_blank">mweil@wustl.edu</a>>>> wrote:<br class="gmail_msg">
<a href="https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/General%20Parallel%20File%20System%20(GPFS)/page/Flash%20Storage" rel="noreferrer" class="gmail_msg" target="_blank">https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/General%20Parallel%20File%20System%20(GPFS)/page/Flash%20Storage</a><<a href="https://www.ibm.com/developerworks/community/wikis/home?lang=en#%21/wiki/General%20Parallel%20File%20System%20%28GPFS%29/page/Flash%20Storage" rel="noreferrer" class="gmail_msg" target="_blank">https://www.ibm.com/developerworks/community/wikis/home?lang=en#%21/wiki/General%20Parallel%20File%20System%20%28GPFS%29/page/Flash%20Storage</a>><br class="gmail_msg">
<br class="gmail_msg">
Hello all,<br class="gmail_msg">
<br class="gmail_msg">
Are there any tuning recommendations to get these to cache more metadata?<br class="gmail_msg">
<br class="gmail_msg">
Thanks<br class="gmail_msg">
<br class="gmail_msg">
Matt<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
gpfsug-discuss mailing list<br class="gmail_msg">
gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" class="gmail_msg" target="_blank">spectrumscale.org</a><<a href="http://spectrumscale.org" rel="noreferrer" class="gmail_msg" target="_blank">http://spectrumscale.org</a>><<a href="http://spectrumscale.org" rel="noreferrer" class="gmail_msg" target="_blank">http://spectrumscale.org</a>><br class="gmail_msg">
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" class="gmail_msg" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
gpfsug-discuss mailing list<br class="gmail_msg">
gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" class="gmail_msg" target="_blank">spectrumscale.org</a><<a href="http://spectrumscale.org" rel="noreferrer" class="gmail_msg" target="_blank">http://spectrumscale.org</a>><<a href="http://spectrumscale.org" rel="noreferrer" class="gmail_msg" target="_blank">http://spectrumscale.org</a>><br class="gmail_msg">
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" class="gmail_msg" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
gpfsug-discuss mailing list<br class="gmail_msg">
gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" class="gmail_msg" target="_blank">spectrumscale.org</a><<a href="http://spectrumscale.org" rel="noreferrer" class="gmail_msg" target="_blank">http://spectrumscale.org</a>><<a href="http://spectrumscale.org" rel="noreferrer" class="gmail_msg" target="_blank">http://spectrumscale.org</a>><br class="gmail_msg">
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" class="gmail_msg" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
gpfsug-discuss mailing list<br class="gmail_msg">
gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" class="gmail_msg" target="_blank">spectrumscale.org</a><<a href="http://spectrumscale.org" rel="noreferrer" class="gmail_msg" target="_blank">http://spectrumscale.org</a>><br class="gmail_msg">
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" class="gmail_msg" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
gpfsug-discuss mailing list<br class="gmail_msg">
gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" class="gmail_msg" target="_blank">spectrumscale.org</a><br class="gmail_msg">
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" class="gmail_msg" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br class="gmail_msg">
</blockquote></div>