<div dir="auto">Have disabled prefetching on the FS7200?</div><div dir="auto"><br></div><div dir="auto">chsystem -cache_prefetch off</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">  -jf</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">ons. 14. feb. 2024 kl. 19:31 skrev Michal Hruška <<a href="mailto:Michal.Hruska@mcomputers.cz">Michal.Hruska@mcomputers.cz</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">





<div lang="CS" link="#0563C1" vlink="#954F72">
<div class="m_-7166401255418160184WordSection1">
<p class="MsoNormal"><span lang="EN-US">Dear friends,</span><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Thank you all for your time and thoughts/ideas!<br>
<br>
<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">The main goal for sharing our test results comparing XFS and GPFS was to show, that the storage subsystem is able to do better if the I/O is provided in different way. We were not trying to compare XFS and GPFS directly,
 we understand that there will be some performance drop using GPFS (compared to “raw” performance) but we are just surprised by the ~20-25% performance drop.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">We tried to change multiple suggested parameters but we got no performance gain. As there was no change we tried to do more troubleshooting using different configurations.<br>
<br>
<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">To better understand what we tried I have to describe our environment a bit more:<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Our underlying storage system is IBM FS7300 (each controller has 384 GB cache). There are 8 DRAIDs (8+2+1). Each DRAID has its own pool and each pool has one Volume (LUN). Every FE server (we have 3 of them) is connected
 directly to this storage using two 32 GFC connections. 3 client servers and FE servers are connected to LAN switch using 100GbE connection.
<br>
<br>
<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Testing results (metadata are located on NVMe SSD DRAID):<u></u><u></u></span></p>
<ol style="margin-top:0cm" start="1" type="1">
<li class="m_-7166401255418160184MsoListParagraphCxSpFirst" style="margin-left:0cm">
<span lang="EN-US">We used second - identical storage to test the performance but we are getting almost the same results compared to first storage. In iohist we can see that one LUN (dm-device) is probably overloaded as IO time is high – from 300 to 500 ms. 
<u></u><u></u></span></li><li class="m_-7166401255418160184MsoListParagraphCxSpMiddle" style="margin-left:0cm">
<span lang="EN-US">Using both storage systems together in one big FS (GPFS): always is only one dm-device slow (according to iohist output) but the “problematic” dm-device changes in time.<u></u><u></u></span></li><li class="m_-7166401255418160184MsoListParagraphCxSpMiddle" style="margin-left:0cm">
<span lang="EN-US">During out tests we also tried synchronous fio test but we observed significant performance drop.<u></u><u></u></span></li><li class="m_-7166401255418160184MsoListParagraphCxSpLast" style="margin-left:0cm">
<span lang="EN-US">We tried to compare single LUN performance GPFS against XFS: GPFS 435MB/s compared to XFS 485MB/s. From single server. The drop is not so significant but when we added more LUNs to the comparison the performance drop was more painful.<u></u><u></u></span></li></ol>
<p class="MsoNormal"><span lang="EN-US">For this testing “session” we were able to gather data by Storage Insights to check storage performance:<u></u><u></u></span></p>
<ol style="margin-top:0cm" start="1" type="1">
<li class="m_-7166401255418160184MsoListParagraphCxSpFirst" style="margin-left:0cm">
<span lang="EN-US">There is no problematic HDD – the worst latency seen is 42ms from all 176 drives in two storage systems. Average latency is 15ms.<u></u><u></u></span></li><li class="m_-7166401255418160184MsoListParagraphCxSpMiddle" style="margin-left:0cm">
<span lang="EN-US">CPU usage was at 25% max.<u></u><u></u></span></li><li class="m_-7166401255418160184MsoListParagraphCxSpMiddle" style="margin-left:0cm">
<span lang="EN-US">“Problematic” DRAID latency – average is 16ms the worst is 430ms. I can not tell if there was the same peak in latency during XFS tests but I think that no (or not so bad) – as the XFS is able to perform better than GPFS.
<u></u><u></u></span></li><li class="m_-7166401255418160184MsoListParagraphCxSpLast" style="margin-left:0cm">
<span lang="EN-US">During our tests the write cache for all pools was fully allocated. Both for XFS and GPFS tests. Which is expected state as the cache is much faster than HDDs and it should help organize writes before they are forwarded to RAID groups.<u></u><u></u></span></li></ol>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Do you see some other possible problems we missed?
<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">I do not want to leave it behind “unfinished” but I am out of ideas.
</span><span lang="EN-US" style="font-family:"Segoe UI Emoji",sans-serif">😊</span><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Best,<br>
Michal<br>
<br>
<u></u><u></u></p>
<div>
<div style="border-width:1pt medium medium;border-style:solid none none;padding:3pt 0cm 0cm;border-color:rgb(225,225,225) currentcolor currentcolor">
<p class="MsoNormal"><b><span>From:</span></b><span> Michal Hruška
<br>
<b>Sent:</b> Thursday, February 8, 2024 3:59 PM<br>
<b>To:</b> '<a href="mailto:gpfsug-discuss@gpfsug.org" target="_blank">gpfsug-discuss@gpfsug.org</a>' <<a href="mailto:gpfsug-discuss@gpfsug.org" target="_blank">gpfsug-discuss@gpfsug.org</a>><br>
<b>Subject:</b> Re: [gpfsug-discuss] sequential I/O write - performance<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">@Aaron<u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:12pt">Yes, I can confirm that 2MB blocks are transfered over.<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" style="margin-bottom:12pt">/dev/fs0<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:9pt;font-family:Verdana,sans-serif;color:rgb(89,89,89)">Best,<br>
Michal<u style="font-family:Verdana,sans-serif"></u><u style="font-family:Verdana,sans-serif"></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" target="_blank">gpfsug.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org" rel="noreferrer" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org</a><br>
</blockquote></div></div>