<font size=2 face="sans-serif">Hi,</font><br><br><font size=2 face="sans-serif">Try enabling the following in the BIOS
of the NSD servers (screen shots below) </font><ul><li><font size=2 face="sans-serif">Turbo Mode - Enable</font><li><font size=2 face="sans-serif">QPI Link Frequency - Max Performance</font><li><font size=2 face="sans-serif">Operating Mode - Maximum Performance</font><li><p><font size=2 face="Arial">>>>>While we have even better
performance with sequential reads on raw storage LUNS, using GPFS we can
only reach 1GB/s in total (each nsd server seems limited by 0,5GB/s) independent
of the number of clients   </font><p><font size=2 face="Arial">>>We are testing from 2 testing machines
connected to the nsds with infiniband, verbs enabled.</font></ul><br><font size=2 face="sans-serif">Also, It will be good to verify that
all the GPFS nodes have Verbs RDMA started using "mmfsadm test verbs
status" and that the NSD client-server communication from client to
server during "dd" is actually using Verbs RDMA using "mmfsadm
test verbs conn" command  (on NSD client doing dd). If not, then
GPFS might be using TCP/IP network over which the cluster is configured
impacting performance (If this is the case, GPFS mmfs.log.latest for any
Verbs RDMA related errors and resolve). </font><br><ul><li></ul><img src=cid:_1_0C23FAA00C23F078004D07E085258109 style="border:0px solid;"><br><img src=cid:_1_0C2406680C240210004D07E585258109 style="border:0px solid;"><br><img src=cid:_1_0C2412580C240E00004D07EA85258109 style="border:0px solid;"><br><br><font size=2 face="sans-serif">Regards,</font><br><font size=2 face="sans-serif">-Kums</font><br><br><br><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">"Knister, Aaron
S. (GSFC-606.2)[COMPUTER SCIENCE CORP]" <aaron.s.knister@nasa.gov></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 09:11 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=3>Fantastic news! It might also be worth running "cpupower
monitor" or "turbostat" on your NSD servers while you're
running dd tests from the clients to see what CPU frequency your cores
are actually running at.  </font><br><br><font size=3>A typical NSD server workload (especially with IB verbs
and for reads) can be pretty light on CPU which might not prompt your CPU
crew governor to up the frequency (which can affect throughout). If your
frequency scaling governor isn't kicking up the frequency of your CPUs
I've seen that cause this behavior in my testing.  </font><br><br><font size=3>-Aaron</font><br><font size=3><br><br><br></font><br><font size=3>On April 21, 2017 at 05:43:40 EDT, Kenneth Waegeman <kenneth.waegeman@ugent.be>
wrote:</font><p><font size=3>Hi, </font><p><font size=3>We are running a test setup with 2 NSD Servers backed by
4 Dell Powervaults MD3460s. nsd00 is primary serving LUNS of controller
A of the 4 powervaults, nsd02 is primary serving LUNS of controller B.
</font><p><font size=3>We are testing from 2 testing machines connected to the
nsds with infiniband, verbs enabled.</font><p><font size=3>When we do dd from the NSD servers, we see indeed performance
going to 5.8GB/s for one nsd, 7.2GB/s for the two! So it looks like GPFS
is able to get the data at a decent speed. Since we can write from the
clients at a good speed, I didn't suspect the communication between clients
and nsds being the issue, especially since total performance stays the
same using 1 or multiple clients. <br><br>I'll use the nsdperf tool to see if we can find anything, <br><br>thanks!<br><br>K<br></font><br><font size=3>On 20/04/17 17:04, Knister, Aaron S. (GSFC-606.2)[COMPUTER
SCIENCE CORP] wrote:</font><br><font size=3>Interesting. Could you share a little more about your
architecture? Is it possible to mount the fs on an NSD server and do some
dd's from the fs on the NSD server? If that gives you decent performance
perhaps try NSDPERF next </font><a href="https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/General+Parallel+File+System+(GPFS)/page/Testing+network+performance+with+nsdperf"><font size=3 color=blue><u>https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/General+Parallel+File+System+(GPFS)/page/Testing+network+performance+with+nsdperf</u></font></a><font size=3></font><br><br><font size=3>-Aaron</font><br><font size=3><br><br><br></font><br><font size=3>On April 20, 2017 at 10:53:47 EDT, Kenneth Waegeman </font><a href=mailto:kenneth.waegeman@ugent.be><font size=3 color=blue><u><kenneth.waegeman@ugent.be></u></font></a><font size=3>wrote:</font><p><font size=3>Hi,</font><p><p><font size=3>Having an issue that looks the same as this one: </font><p><font size=3>We can do sequential writes to the filesystem at 7,8 GB/s
total , which is the expected speed for our current storage    <br>backend.  While we have even better performance with sequential reads
on raw storage LUNS, using GPFS we can only reach 1GB/s in total (each
nsd 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,
MaxMBps, PrefetchThreads, hyperthreading, c1e/cstates, .. as discussed
in this thread, but nothing seems to impact this read performance. </font><p><font size=3>Any ideas?</font><p><font size=3>Thanks!<br><br>Kenneth<br></font><br><font size=3>On 17/02/17 19:29, Jan-Frode Myklebust wrote:</font><br><font size=3>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. and 250-300 Mbyte/s on sequential reads!! Random reads were on
the order of 2 Gbyte/s.<br><br>After a bit head scratching snd fumbling around I found out that reducing
maxMBpS from 10000 to 100 fixed the problem! Digging further I found that
reducing prefetchThreads from default=72 to 32 also fixed it, while 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</font><br><font size=3>fre. 17. feb. 2017 kl. 18.13 skrev Aaron Knister <</font><a href=mailto:aaron.s.knister@nasa.gov></a><a href=mailto:aaron.s.knister@nasa.gov><font size=3 color=blue><u>aaron.s.knister@nasa.gov</u></font></a><font size=3>>:</font><br><font size=3>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 on one socket, you push all the interrupt handling to the other socket
where the fabric card is attached?<br>><br>> Dunno ... (Though I am intrigued you use idataplex nodes as NSD servers,
I assume its some 2U gpu-tray riser one or something !)<br>><br>> Simon<br>> ________________________________________<br>> From: </font><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" target=_blank><font size=3 color=blue><u>gpfsug-discuss-bounces@spectrumscale.org</u></font></a><font size=3>[</font><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" target=_blank></a><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org"><font size=3 color=blue><u>gpfsug-discuss-bounces@spectrumscale.org</u></font></a><font size=3>]
on behalf of Aaron Knister [</font><a href=mailto:aaron.s.knister@nasa.gov target=_blank></a><a href=mailto:aaron.s.knister@nasa.gov><font size=3 color=blue><u>aaron.s.knister@nasa.gov</u></font></a><font size=3>]<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 </font><a href=http://spectrumscale.org/ target=_blank><font size=3 color=blue><u>spectrumscale.org</u></font></a><font size=3><br>> </font><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target=_blank><font size=3 color=blue><u>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</u></font></a><font size=3><br>> _______________________________________________<br>> gpfsug-discuss mailing list<br>> gpfsug-discuss at </font><a href=http://spectrumscale.org/ target=_blank><font size=3 color=blue><u>spectrumscale.org</u></font></a><font size=3><br>> </font><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target=_blank><font size=3 color=blue><u>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</u></font></a><font size=3><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 </font><a href=http://spectrumscale.org/ target=_blank><font size=3 color=blue><u>spectrumscale.org</u></font></a><font size=3 color=blue><u><br></u></font><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target=_blank><font size=3 color=blue><u>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</u></font></a><br><font size=3><br></font><br><tt><font size=3>_______________________________________________<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=3 color=blue><u>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</u></font></tt></a><tt><font size=3><br></font></tt><br><br><font size=3><br></font><br><tt><font size=3>_______________________________________________<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=3 color=blue><u>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</u></font></tt></a><tt><font size=3><br></font></tt><br><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>