<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<!-- signature -->
<div style="color:rgb(31, 73, 125);">Understood. Thank you for your help.&nbsp;</div>
<div style="color:rgb(31, 73, 125);"><br>
</div>
<div style="color:rgb(31, 73, 125);">By the way, I was able to figure out by poking mmpmon gfis that the job is performing 20k a second each of inode creations, updates and deletions across 64 nodes. There's my 60k iops on the backend. While I'm impressed and
 not surprised GPFS can keep up with this...that's a pretty hefty workload.&nbsp;</div>
<div style="color:rgb(31, 73, 125);"><br>
</div>
<font style="color:rgb(31, 73, 125)"></font><!-- quoted content --><br>
<br>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:&quot;Helvetica&quot;,&quot;sans-serif&quot;">From:</span></b><span style="font-size:10.0pt;font-family:&quot;Helvetica&quot;,&quot;sans-serif&quot;"> Olaf Weiser<br>
<b>Sent:</b> 10/15/16, 12:47 PM<br>
<b>To:</b> gpfsug main discussion list<br>
<b>Subject:</b> Re: [gpfsug-discuss] SGExceptionLogBufferFullThread waiter<o:p></o:p></span></p>
</div>
</div>
<font size="2" face="     Arial">well - hard to say.. 60K IO may or may not be a problem... it depends on your storage backends..
</font><br>
<br>
<font size="2" face="     Arial">check the response times to the physical disk on the NSD server... concerning the output you provided ... check particularly
</font><br>
<font size="2" face="     Arial">10.1.53.5 &lt;c0n20&gt; and 10.1.53.7 </font><br>
<br>
<font size="2" face="     Arial">.... if they are in the same (bad/ poor) range .. then your storage back end is in trouble or maybe just too heavily utilized ...
</font><br>
<font size="2" face="     Arial">&nbsp;if the response times to physical disks on the NSD server are ok... .. than maybe the network from client &lt;--&gt; &nbsp;NSD server is somehow in trouble ..
</font><br>
<br>
<br>
<br>
<br>
<font size="1" color="#5f5f5f" face="sans-serif">From: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size="1" face="sans-serif">Aaron Knister &lt;aaron.s.knister@nasa.gov&gt;</font><br>
<font size="1" color="#5f5f5f" face="sans-serif">To: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size="1" face="sans-serif">&lt;gpfsug-discuss@spectrumscale.org&gt;</font><br>
<font size="1" color="#5f5f5f" face="sans-serif">Date: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size="1" face="sans-serif">10/15/2016 08:28 AM</font><br>
<font size="1" color="#5f5f5f" face="sans-serif">Subject: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size="1" face="sans-serif">Re: [gpfsug-discuss] SGExceptionLogBufferFullThread waiter</font><br>
<font size="1" color="#5f5f5f" face="sans-serif">Sent by: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size="1" face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br>
<hr noshade="">
<br>
<br>
<br>
<tt><font size="2">It absolutely does, thanks Olaf!<br>
<br>
The tasks running on these nodes are running on 63 other nodes and <br>
generating ~60K iop/s of metadata writes and I *think* about the same in <br>
reads. Do you think that could be contributing to the higher waiter <br>
times? I'm not sure quite what the job is up to. It's seemingly doing <br>
very little data movement, the cpu %used is very low but the load is <br>
rather high.<br>
<br>
-Aaron<br>
<br>
On 10/15/16 11:23 AM, Olaf Weiser wrote:<br>
&gt; from your file system configuration .. mmfs &lt;dev&gt; -L you'll find the<br>
&gt; size of the LOG<br>
&gt; since release 4.x ..you can change it, but you need to re-mount the FS<br>
&gt; on every client , to make the change effective ...<br>
&gt;<br>
&gt; when a clients initiate writes/changes to GPFS &nbsp;it needs to update its<br>
&gt; changes to the log - &nbsp;if this narrows a certain filling degree, GPFS<br>
&gt; triggers so called logWrapThreads to write content to disk and so free<br>
&gt; space<br>
&gt;<br>
&gt; with your given numbers ... double digit [ms] waiter times .. you fs<br>
&gt; get's probably slowed down.. and there's something suspect with the<br>
&gt; storage, because LOG-IOs are rather small and should not take that long<br>
&gt;<br>
&gt; to give you an example from a healthy environment... the IO times are so<br>
&gt; small, that you usually don't see waiters for this..<br>
&gt;<br>
&gt; I/O start time RW &nbsp; &nbsp;Buf type disk:sectorNum &nbsp; &nbsp; nSec &nbsp;time ms &nbsp; &nbsp; &nbsp;tag1<br>
&gt; &nbsp; &nbsp; &nbsp;tag2 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Disk UID typ &nbsp; &nbsp; &nbsp;NSD node context &nbsp; thread<br>
&gt; --------------- -- ----------- ----------------- ----- &nbsp;-------<br>
&gt; --------- --------- ------------------ --- --------------- ---------<br>
&gt; ----------<br>
&gt; 06:23:32.358851 &nbsp;W &nbsp; &nbsp; logData &nbsp; &nbsp;2:524306424 &nbsp; &nbsp; &nbsp; &nbsp;8 &nbsp; &nbsp;0.439<br>
&gt; 0 &nbsp; &nbsp; &nbsp; &nbsp; 0 &nbsp;C0A70D08:57CF40D1 cli &nbsp; 192.167.20.17 LogData<br>
&gt; SGExceptionLogBufferFullThread<br>
&gt; 06:23:33.576367 &nbsp;W &nbsp; &nbsp; logData &nbsp; &nbsp;1:524257280 &nbsp; &nbsp; &nbsp; &nbsp;8 &nbsp; &nbsp;0.646<br>
&gt; 0 &nbsp; &nbsp; &nbsp; &nbsp; 0 &nbsp;C0A70D08:57CF40D0 cli &nbsp; 192.167.20.16 LogData<br>
&gt; SGExceptionLogBufferFullThread<br>
&gt; 06:23:32.358851 &nbsp;W &nbsp; &nbsp; logData &nbsp; &nbsp;2:524306424 &nbsp; &nbsp; &nbsp; &nbsp;8 &nbsp; &nbsp;0.439<br>
&gt; 0 &nbsp; &nbsp; &nbsp; &nbsp; 0 &nbsp;C0A70D08:57CF40D1 cli &nbsp; 192.167.20.17 LogData<br>
&gt; SGExceptionLogBufferFullThread<br>
&gt; 06:23:33.576367 &nbsp;W &nbsp; &nbsp; logData &nbsp; &nbsp;1:524257280 &nbsp; &nbsp; &nbsp; &nbsp;8 &nbsp; &nbsp;0.646<br>
&gt; 0 &nbsp; &nbsp; &nbsp; &nbsp; 0 &nbsp;C0A70D08:57CF40D0 cli &nbsp; 192.167.20.16 LogData<br>
&gt; SGExceptionLogBufferFullThread<br>
&gt; 06:23:32.212426 &nbsp;W &nbsp; iallocSeg &nbsp; &nbsp;1:524490048 &nbsp; &nbsp; &nbsp; 64 &nbsp; &nbsp;0.733<br>
&gt; 2 &nbsp; &nbsp; &nbsp; 245 &nbsp;C0A70D08:57CF40D0 cli &nbsp; 192.167.20.16 Logwrap<br>
&gt; LogWrapHelperThread<br>
&gt; 06:23:32.212412 &nbsp;W &nbsp; &nbsp; logWrap &nbsp; &nbsp;2:524552192 &nbsp; &nbsp; &nbsp; &nbsp;8 &nbsp; &nbsp;0.755<br>
&gt; 0 &nbsp; &nbsp;179200 &nbsp;C0A70D08:57CF40D1 cli &nbsp; 192.167.20.17 Logwrap<br>
&gt; LogWrapHelperThread<br>
&gt; 06:23:32.212432 &nbsp;W &nbsp; &nbsp; logWrap &nbsp; &nbsp;2:525162760 &nbsp; &nbsp; &nbsp; &nbsp;8 &nbsp; &nbsp;0.737<br>
&gt; 0 &nbsp; &nbsp;125473 &nbsp;C0A70D08:57CF40D1 cli &nbsp; 192.167.20.17 Logwrap<br>
&gt; LogWrapHelperThread<br>
&gt; 06:23:32.212416 &nbsp;W &nbsp; iallocSeg &nbsp; &nbsp;2:524488384 &nbsp; &nbsp; &nbsp; 64 &nbsp; &nbsp;0.763<br>
&gt; 2 &nbsp; &nbsp; &nbsp; 347 &nbsp;C0A70D08:57CF40D1 cli &nbsp; 192.167.20.17 Logwrap<br>
&gt; LogWrapHelperThread<br>
&gt; 06:23:32.212414 &nbsp;W &nbsp; &nbsp; logWrap &nbsp; &nbsp;2:525266944 &nbsp; &nbsp; &nbsp; &nbsp;8 &nbsp; &nbsp;2.160<br>
&gt; 0 &nbsp; &nbsp;177664 &nbsp;C0A70D08:57CF40D1 cli &nbsp; 192.167.20.17 Logwrap<br>
&gt; LogWrapHelperThread<br>
&gt;<br>
&gt;<br>
&gt; hope this helps ..<br>
&gt;<br>
&gt;<br>
&gt; Mit freundlichen Gren / Kind regards<br>
&gt;<br>
&gt;<br>
&gt; Olaf Weiser<br>
&gt;<br>
&gt; EMEA Storage Competence Center Mainz, German / IBM Systems, Storage<br>
&gt; Platform,<br>
&gt; -------------------------------------------------------------------------------------------------------------------------------------------<br>
&gt; IBM Deutschland<br>
&gt; IBM Allee 1<br>
&gt; 71139 Ehningen<br>
&gt; Phone: &#43;49-170-579-44-66<br>
&gt; E-Mail: olaf.weiser@de.ibm.com<br>
&gt; -------------------------------------------------------------------------------------------------------------------------------------------<br>
&gt; IBM Deutschland GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter<br>
&gt; Geschftsfhrung: Martina Koederitz (Vorsitzende), Susanne Peter,<br>
&gt; Norbert Janzen, Dr. Christian Keller, Ivo Koerner, Markus Koerner<br>
&gt; Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht<br>
&gt; Stuttgart, HRB 14562 / WEEE-Reg.-Nr. DE 99369940<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; From: &nbsp; &nbsp; &nbsp; &nbsp;Aaron Knister &lt;aaron.s.knister@nasa.gov&gt;<br>
&gt; To: &nbsp; &nbsp; &nbsp; &nbsp;gpfsug main discussion list &lt;gpfsug-discuss@spectrumscale.org&gt;<br>
&gt; Date: &nbsp; &nbsp; &nbsp; &nbsp;10/15/2016 07:23 AM<br>
&gt; Subject: &nbsp; &nbsp; &nbsp; &nbsp;[gpfsug-discuss] SGExceptionLogBufferFullThread waiter<br>
&gt; Sent by: &nbsp; &nbsp; &nbsp; &nbsp;gpfsug-discuss-bounces@spectrumscale.org<br>
&gt; ------------------------------------------------------------------------<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; I've got a node that's got some curious waiters on it (see below). Could<br>
&gt; someone explain what the &quot;SGExceptionLogBufferFullThread&quot; waiter means?<br>
&gt;<br>
&gt; Thanks!<br>
&gt;<br>
&gt; -Aaron<br>
&gt;<br>
&gt; === mmdiag: waiters ===<br>
&gt; 0x7FFFF040D600 waiting 0.038822715 seconds,<br>
&gt; SGExceptionLogBufferFullThread: on ThCond 0x7FFFDBB07628<br>
&gt; (0x7FFFDBB07628) (parallelWaitCond), reason 'wait for parallel write'<br>
&gt; for NSD I/O completion on node 10.1.53.5 &lt;c0n20&gt;<br>
&gt; 0x7FFFE83F3D60 waiting 0.039629116 seconds, CleanBufferThread: on ThCond<br>
&gt; 0x17B1488 (0x17B1488) (MsgRecordCondvar), reason 'RPC wait' for NSD I/O<br>
&gt; completion on node 10.1.53.7 &lt;c0n22&gt;<br>
&gt; 0x7FFFE8373A90 waiting 0.038921480 seconds, CleanBufferThread: on ThCond<br>
&gt; 0x7FFFCD2B4E30 (0x7FFFCD2B4E30) (LogFileBufferDescriptorCondvar), reason<br>
&gt; 'force wait on force active buffer write'<br>
&gt; 0x42CD9B0 waiting 0.028227004 seconds, CleanBufferThread: on ThCond<br>
&gt; 0x7FFFCD2B4E30 (0x7FFFCD2B4E30) (LogFileBufferDescriptorCondvar), reason<br>
&gt; 'force wait for buffer write to complete'<br>
&gt; 0x7FFFE0F0EAD0 waiting 0.027864343 seconds, CleanBufferThread: on ThCond<br>
&gt; 0x7FFFDC0EEA88 (0x7FFFDC0EEA88) (MsgRecordCondvar), reason 'RPC wait'<br>
&gt; for NSD I/O completion on node 10.1.53.7 &lt;c0n22&gt;<br>
&gt; 0x1575560 waiting 0.028045975 seconds, RemoveHandlerThread: on ThCond<br>
&gt; 0x18020CE4E08 (0xFFFFC90020CE4E08) (LkObjCondvar), reason 'waiting for<br>
&gt; LX lock'<br>
&gt; 0x1570560 waiting 0.038724949 seconds, CreateHandlerThread: on ThCond<br>
&gt; 0x18020CE50A0 (0xFFFFC90020CE50A0) (LkObjCondvar), reason 'waiting for<br>
&gt; LX lock'<br>
&gt; 0x1563D60 waiting 0.073919918 seconds, RemoveHandlerThread: on ThCond<br>
&gt; 0x180235F6440 (0xFFFFC900235F6440) (LkObjCondvar), reason 'waiting for<br>
&gt; LX lock'<br>
&gt; 0x1561560 waiting 0.054854513 seconds, RemoveHandlerThread: on ThCond<br>
&gt; 0x1802292D200 (0xFFFFC9002292D200) (LkObjCondvar), reason 'waiting for<br>
&gt; LX lock'<br>
&gt; _______________________________________________<br>
&gt; gpfsug-discuss mailing list<br>
&gt; gpfsug-discuss at spectrumscale.org<br>
&gt; </font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_BLANK"><tt><font size="2">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></tt></a><tt><font size="2"><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; gpfsug-discuss mailing list<br>
&gt; gpfsug-discuss at spectrumscale.org<br>
&gt; </font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_BLANK"><tt><font size="2">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></tt></a><tt><font size="2"><br>
&gt;<br>
_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at spectrumscale.org<br>
</font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_BLANK"><tt><font size="2">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></tt></a><tt><font size="2"><br>
<br>
</font></tt><br>
<br>
<br>
</body>
</html>