<font size=2 face="sans-serif">pls check</font><br><font size=2 face="sans-serif">workerThreads  (assuming you 're

 > 4.2.2) start with 128 .. increase iteratively </font><br><font size=2 face="sans-serif">pagepool  at least 8 G</font><br><font size=2 face="sans-serif">ignorePrefetchLunCount=yes (1) </font><br><br><font size=2 face="sans-serif">then you won't see a difference and

GPFS is as fast or even faster .. </font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:      

 </font><font size=1 face="sans-serif">"Marcus Koenig1"

<marcusk@nz1.ibm.com></font><br><font size=1 color=#5f5f5f face="sans-serif">To:      

 </font><font size=1 face="sans-serif">gpfsug main discussion

list <gpfsug-discuss@spectrumscale.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:      

 </font><font size=1 face="sans-serif">04/21/2017 03:24 AM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:    

   </font><font size=1 face="sans-serif">Re: [gpfsug-discuss]

bizarre performance behavior</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:    

   </font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr noshade><br><br><br><font size=2>Hi Kennmeth,</font><font size=3><br></font><font size=2><br>we also had similar performance numbers in our tests. Native was far quicker

than through GPFS. When we learned though that the client tested the performance

on the FS at a big blocksize (512k) with small files - we were able to

speed it up significantly using a smaller FS blocksize (obviously we had

to recreate the FS).</font><font size=3><br></font><font size=2><br>So really depends on how you do your tests.</font><p><font size=3 color=#8f8f8f face="Arial"><b>Cheers,</b></font><font size=3><br></font><font size=3 color=#8f8f8f face="Arial"><b><br>Marcus Koenig</b></font><font size=2 face="Arial"><br>Lab Services Storage & Power Specialist</font><font size=2 face="Calibri"><i><br>IBM Australia & New Zealand Advanced Technical Skills</i></font><font size=2 face="Arial"><br>IBM Systems-Hardware</font><table width=943 style="border-collapse:collapse;"><tr height=8><td width=678 colspan=3 style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><hr><td width=264 valign=top style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><img align=bottom src=cid:_1_0AD124480AD1202C0027E608C1258109 width=1 height=1 style="border:0px solid;"><tr valign=top height=8><td width=119 style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><img align=bottom src=cid:_1_0AD12A5C0AD126700027E608C1258109 style="border:0px solid;"><td width=219 style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><font size=1 color=#4181c0 face="Arial"><b>Mobile:</b></font><font size=1 color=#5f5f5f face="Arial">+64 21 67 34 27</font><font size=1 color=#4181c0 face="Arial"><b><br>E-mail:</b></font><font size=1 color=#5f5f5f face="Arial"> </font><a href=mailto:brendanp@nz1.ibm.com target=_blank><font size=1 color=#5f5f5f face="Arial"><u>marcusk@nz1.ibm.com</u></font></a><p><font size=1 color=#5f5f5f face="Arial">82 Wyndham Street<br>Auckland, AUK 1010<br>New Zealand</font><div align=center><font size=3><br><br></font></div><p><td width=340 style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><div align=center><img align=bottom src=cid:_2_0AD1C3800AD1BF940027E608C1258109 style="border:0px solid;"><img align=bottom src=cid:_4_0AD1C5D80AD1BF940027E608C1258109 width=104 height=52 style="border:0px solid;"></div><td width=264 style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><img align=bottom src=cid:_1_0AD1CD4C0AD1C9300027E608C1258109 width=1 height=1 style="border:0px solid;"><tr valign=top height=8><td width=119 style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><img align=bottom src=cid:_1_0AD1D3600AD1CF740027E608C1258109 width=1 height=1 style="border:0px solid;"><td width=219 style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><img align=bottom src=cid:_1_0AD1D9740AD1D5880027E608C1258109 width=1 height=1 style="border:0px solid;"><td width=340 style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><img align=bottom src=cid:_1_0AD1DF880AD1DB9C0027E608C1258109 width=1 height=1 style="border:0px solid;"><td width=264 style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><img align=bottom src=cid:_1_0AD1E59C0AD1E1B00027E608C1258109 width=1 height=1 style="border:0px solid;"></table><br><font size=3><br></font><img src=cid:_1_0AD1E7C40AD10B940027E608C1258109 alt="Inactive hide details for "Uwe Falke" ---04/21/2017 03:07:48 AM---Hi Kennmeth,  is prefetching off or on  at your storage backe" style="border:0px solid;"><font size=2 color=#424282>"Uwe

Falke" ---04/21/2017 03:07:48 AM---Hi Kennmeth, is prefetching off

or on at your storage backend?</font><font size=3><br></font><font size=2 color=#5f5f5f><br>From: </font><font size=2>"Uwe Falke" <UWEFALKE@de.ibm.com></font><font size=2 color=#5f5f5f><br>To: </font><font size=2>gpfsug main discussion list <gpfsug-discuss@spectrumscale.org></font><font size=2 color=#5f5f5f><br>Date: </font><font size=2>04/21/2017 03:07 AM</font><font size=2 color=#5f5f5f><br>Subject: </font><font size=2>Re: [gpfsug-discuss] bizarre performance behavior</font><font size=2 color=#5f5f5f><br>Sent by: </font><font size=2>gpfsug-discuss-bounces@spectrumscale.org</font><font size=3><br></font><hr noshade><font size=3><br><br></font><tt><font size=2><br>Hi Kennmeth, <br><br>is prefetching off or on  at your storage backend?<br>Raw sequential is very different from GPFS sequential at the storage <br>device !<br>GPFS does its own prefetching, the storage would never know what sectors

<br>sequential read at GPFS level maps to at storage level!<br><br><br>Mit freundlichen Grüßen / Kind regards<br><br><br>Dr. Uwe Falke<br><br>IT Specialist<br>High Performance Computing Services / Integrated Technology Services /

<br>Data Center Services<br>-------------------------------------------------------------------------------------------------------------------------------------------<br>IBM Deutschland<br>Rathausstr. 7<br>09111 Chemnitz<br>Phone: +49 371 6978 2165<br>Mobile: +49 175 575 2877<br>E-Mail: uwefalke@de.ibm.com<br>-------------------------------------------------------------------------------------------------------------------------------------------<br>IBM Deutschland Business & Technology Services GmbH / Geschäftsführung:

<br>Andreas Hasse, Thorsten Moehring<br>Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart,

<br>HRB 17122 <br><br><br><br><br>From:   Kenneth Waegeman <kenneth.waegeman@ugent.be><br>To:     gpfsug main discussion list <gpfsug-discuss@spectrumscale.org><br>Date:   04/20/2017 04:53 PM<br>Subject:        Re: [gpfsug-discuss] bizarre performance

behavior<br>Sent by:        gpfsug-discuss-bounces@spectrumscale.org<br><br><br><br>Hi,<br><br>Having an issue that looks the same as this one: <br>We can do sequential writes to the filesystem at 7,8 GB/s total , which

is <br>the expected speed for our current storage    <br>backend.  While we have even better performance with sequential reads

on <br>raw storage LUNS, using GPFS we can only reach 1GB/s in total (each nsd

<br>server seems limited by 0,5GB/s) independent of the number of clients  

<br>(1,2,4,..) or ways we tested (fio,dd). We played with blockdev params,

<br>MaxMBps, PrefetchThreads, hyperthreading, c1e/cstates, .. as discussed

in  this thread, but nothing seems to impact this read performance.  Any ideas? Thanks! Kenneth On 17/02/17 19:29, Jan-Frode Myklebust wrote: I just had a similar experience from a sandisk infiniflash system  SAS-attached to s single host. Gpfsperf reported 3,2 Gbyte/s for writes.

<br>and 250-300 Mbyte/s on sequential reads!! Random reads were on the order

<br>of 2 Gbyte/s.<br><br>After a bit head scratching snd fumbling around I found out that reducing

<br>maxMBpS from 10000 to 100 fixed the problem! Digging further I found that

<br>reducing prefetchThreads from default=72 to 32 also fixed it, while <br>leaving maxMBpS at 10000. Can now also read at 3,2 GByte/s.<br><br>Could something like this be the problem on your box as well?<br><br><br><br>-jf<br>fre. 17. feb. 2017 kl. 18.13 skrev Aaron Knister <aaron.s.knister@nasa.gov<br>>:<br>Well, I'm somewhat scrounging for hardware. This is in our test<br>environment :) And yep, it's got the 2U gpu-tray in it although even<br>without the riser it has 2 PCIe slots onboard (excluding the on-board<br>dual-port mezz card) so I think it would make a fine NSD server even<br>without the riser.<br><br>-Aaron<br><br>On 2/17/17 11:43 AM, Simon Thompson (Research Computing - IT Services)<br>wrote:<br>> Maybe its related to interrupt handlers somehow? You drive the load

up <br>on one socket, you push all the interrupt handling to the other socket

<br>where the fabric card is attached?<br>><br>> Dunno ... (Though I am intrigued you use idataplex nodes as NSD servers,

<br>I assume its some 2U gpu-tray riser one or something !)<br>><br>> Simon<br>> ________________________________________<br>> From: gpfsug-discuss-bounces@spectrumscale.org [<br>gpfsug-discuss-bounces@spectrumscale.org] on behalf of Aaron Knister [<br>aaron.s.knister@nasa.gov]<br>> Sent: 17 February 2017 15:52<br>> To: gpfsug main discussion list<br>> Subject: [gpfsug-discuss] bizarre performance behavior<br>><br>> This is a good one. I've got an NSD server with 4x 16GB fibre<br>> connections coming in and 1x FDR10 and 1x QDR connection going out

to<br>> the clients. I was having a really hard time getting anything resembling<br>> sensible performance out of it (4-5Gb/s writes but maybe 1.2Gb/s for<br>> reads). The back-end is a DDN SFA12K and I *know* it can do better

than<br>> that.<br>><br>> I don't remember quite how I figured this out but simply by running<br>> "openssl speed -multi 16" on the nsd server to drive up

the load I saw<br>> an almost 4x performance jump which is pretty much goes against every<br>> sysadmin fiber in me (i.e. "drive up the cpu load with unrelated

crap to<br>> quadruple your i/o performance").<br>><br>> This feels like some type of C-states frequency scaling shenanigans

that<br>> I haven't quite ironed down yet. I booted the box with the following<br>> kernel parameters "intel_idle.max_cstate=0 processor.max_cstate=0"

which<br>> didn't seem to make much of a difference. I also tried setting the<br>> frequency governer to userspace and setting the minimum frequency

to<br>> 2.6ghz (it's a 2.6ghz cpu). None of that really matters-- I still

have<br>> to run something to drive up the CPU load and then performance improves.<br>><br>> I'm wondering if this could be an issue with the C1E state? I'm curious<br>> if anyone has seen anything like this. The node is a dx360 M4<br>> (Sandybridge) with 16 2.6GHz cores and 32GB of RAM.<br>><br>> -Aaron<br>><br>> --<br>> Aaron Knister<br>> NASA Center for Climate Simulation (Code 606.2)<br>> Goddard Space Flight Center<br>> (301) 286-2776<br>> _______________________________________________<br>> gpfsug-discuss mailing list<br>> gpfsug-discuss at spectrumscale.org<br>> </font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2 color=blue><u>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</u></font></tt></a><tt><font size=2><br>> _______________________________________________<br>> gpfsug-discuss mailing list<br>> gpfsug-discuss at spectrumscale.org<br>> </font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2 color=blue><u>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</u></font></tt></a><tt><font size=2><br>><br><br>--<br>Aaron Knister<br>NASA Center for Climate Simulation (Code 606.2)<br>Goddard Space Flight Center<br>(301) 286-2776<br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org</font></tt><tt><font size=2 color=blue><u><br></u></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2 color=blue><u>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</u></font></tt></a><tt><font size=2><br><br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org</font></tt><tt><font size=2 color=blue><u><br></u></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2 color=blue><u>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</u></font></tt></a><tt><font size=2><br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org</font></tt><tt><font size=2 color=blue><u><br></u></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2 color=blue><u>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</u></font></tt></a><tt><font size=2><br><br><br><br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org</font></tt><tt><font size=2 color=blue><u><br></u></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2 color=blue><u>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</u></font></tt></a><tt><font size=2><br></font></tt><font size=3><br><br><br></font><tt><font size=2>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></tt></a><tt><font size=2><br></font></tt><br><br><BR>