<div dir="auto">This won't affect your current issue but if you're doing a lot of large sequential IO you may want to consider setting prefetchPct to 40 to 60 percent instead of default 20%.  In our environment that has measurable impact, but we have a lot less ram than you do in the pagepool (8g versus 64g).<div dir="auto"><br></div><div dir="auto">Also do you have a dedicated meta pool?  If not that could be a source of contention.  Highly recommend a small pinnable LUN or two as a dedicated meta pool.</div><div dir="auto"><br></div><div dir="auto">Alec</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 8, 2024, 7:01 AM Michal Hruška <<a href="mailto:Michal.Hruska@mcomputers.cz">Michal.Hruska@mcomputers.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="CS" link="#0563C1" vlink="#954F72">
<div class="m_-6093307153041181205WordSection1">
<p class="MsoNormal">@Aaron<u></u><u></u></p>
<p class="MsoNormal">Yes, I can confirm that 2MB blocks are transfered over.<br>
<br>
<u></u><u></u></p>
<p class="MsoNormal">@ Jan-Frode<u></u><u></u></p>
<p class="MsoNormal">We tried to change multiple parameters, but if you know the best combination for sequential IO, please let me know.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">#mmlsconfig<u></u><u></u></p>
<p class="MsoNormal">autoload no<u></u><u></u></p>
<p class="MsoNormal">dmapiFileHandleSize 32<u></u><u></u></p>
<p class="MsoNormal">minReleaseLevel 5.1.9.0<u></u><u></u></p>
<p class="MsoNormal">tscCmdAllowRemoteConnections no<u></u><u></u></p>
<p class="MsoNormal">ccrEnabled yes<u></u><u></u></p>
<p class="MsoNormal">cipherList AUTHONLY<u></u><u></u></p>
<p class="MsoNormal">sdrNotifyAuthEnabled yes<u></u><u></u></p>
<p class="MsoNormal">pagepool 64G<u></u><u></u></p>
<p class="MsoNormal">maxblocksize 16384K<u></u><u></u></p>
<p class="MsoNormal">maxMBpS 40000<u></u><u></u></p>
<p class="MsoNormal">maxReceiverThreads 32<u></u><u></u></p>
<p class="MsoNormal">nsdMaxWorkerThreads 512<u></u><u></u></p>
<p class="MsoNormal">nsdMinWorkerThreads 8<u></u><u></u></p>
<p class="MsoNormal">nsdMultiQueue 256<u></u><u></u></p>
<p class="MsoNormal">nsdSmallThreadRatio 0<u></u><u></u></p>
<p class="MsoNormal">nsdThreadsPerQueue 3<u></u><u></u></p>
<p class="MsoNormal">prefetchAggressiveness 2<u></u><u></u></p>
<p class="MsoNormal">adminMode central<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">/dev/fs0<br>
<br>
<u></u><u></u></p>
<p class="MsoNormal">@Uwe<u></u><u></u></p>
<p class="MsoNormal">Using iohist we found out that gpfs is overloading one dm-device (it took about 500ms to finish IOs). We replaced the „problematic“ dm-device (as we have enough drives to play with) for new one but the overloading issue just jumped to another
 dm-device.<br>
We believe that this behaviour is caused by the gpfs but we are unable to locate the root cause of it.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#595959">Best,<br>
Michal<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>

_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://gpfsug.org" rel="noreferrer noreferrer" target="_blank">gpfsug.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org" rel="noreferrer noreferrer" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org</a><br>
</blockquote></div>