<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">So, this failure is related to patch [1] iobuf. Thanks to Pranith for identifying this. This patch increases the memory consumption in the brick mux use case(**) and causes oom kill. But it is not the problem with the patch itself. The only way to rightly fix it is to fix the issue [2]. That said we cannot wait until this issue is fixed, the possible work arounds are:</div><div>- Reduce the volume creation count in test case mpx-restart-crash.t (temporarily until [2] is fixed)<br></div><div>- Increase the resources(RAM to 4G?) on the regression system</div><div>- Revert the patch until [2] is completely fixed</div><div dir="ltr"></div><div dir="ltr"><br></div><div>Root Cause:</div><div>Without the iobuf patch [1], we had a pre allocated pool of min size 12.5MB(which can grow), in many cases this entire size may not be completely used. Hence we moved to per thread mem pool for iobuf as well. With this we expect the memory consumption of the processes to go down, and it did go down.After creating 20 volumes on the system, the free -m output:</div><div>With this patch:</div><div> total used free shared buff/cache available<br>Mem: 3789 2198 290 249 1300 968<br>Swap: 3071 0 3071<br><br></div><div>Without this patch:</div><div> total used free shared buff/cache available<br>Mem: 3789 2280 115 488 1393 647<br>Swap: 3071 0 3071<br></div><div>This output can vary based on system state, workload etc. This is not indicative of the exact amount of memory reduction, but of the fact that the memory usage is reduced.<br></div><div><br></div><div>But, with brick mux the scenario is different. Since we use per thread mem pool for iobuf in patch [1], the memory consumption due to iobuf increases if the threads increases. In the current brick mux implementation, for 20 volumes(in the mpx-restart-crash test), the number of threads is 1439. And the allocated iobufs(or any other per thread mem pool memory) doesn't get freed until 30s(garbage collection time) of issuing free(eg: iobuf_put). As a result of this the memory consumption of the process appears to increase for brick mux. Reducing the number of threads to <100 [2] will solve this issue. To prove this theory, if we add 30sec delay between each volume create in mpx-restart-crash, the mem consumption is:</div><div><br></div><div>With this patch after adding 30s delay between create volume:</div><div> total used free shared buff/cache available<br>Mem: 3789 1344 947 488 1497 1606<br>Swap: 3071 0 3071<br></div><div><br></div><div>With this patch:</div> total used free shared buff/cache available<br>Mem: 3789 1710 840 235 1238 1494<br>Swap: 3071 0 3071</div><div dir="ltr"><br><div>Without this patch:</div><div> total used free shared buff/cache available<br>Mem: 3789 1413 969 355 1406 1668<br>Swap: 3071 0 3071<br></div><div> <br></div><div>Regards,</div><div>Poornima<br></div><div dir="ltr"><br></div><div dir="ltr">[1] <a href="https://review.gluster.org/#/c/glusterfs/+/20362/">https://review.gluster.org/#/c/glusterfs/+/20362/</a></div><div dir="ltr">[2] <a href="https://github.com/gluster/glusterfs/issues/475">https://github.com/gluster/glusterfs/issues/475</a><br></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 20, 2018 at 10:28 AM Amar Tumballi <<a href="mailto:atumball@redhat.com">atumball@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><pre class="gmail-m_6796607542332356564gmail-console-output" style="box-sizing:border-box;white-space:pre-wrap;margin-top:0px;margin-bottom:0px;color:rgb(51,51,51);font-size:15px">Since yesterday at least 10+ patches have failed regression on ./tests/bugs/core/bug-1432542-mpx-restart-crash.t</pre><pre class="gmail-m_6796607542332356564gmail-console-output" style="box-sizing:border-box;white-space:pre-wrap;margin-top:0px;margin-bottom:0px;color:rgb(51,51,51);font-size:15px"><br></pre><pre class="gmail-m_6796607542332356564gmail-console-output" style="box-sizing:border-box;white-space:pre-wrap;margin-top:0px;margin-bottom:0px;color:rgb(51,51,51);font-size:15px">Help to debug them soon would be appreciated.</pre><pre class="gmail-m_6796607542332356564gmail-console-output" style="box-sizing:border-box;white-space:pre-wrap;margin-top:0px;margin-bottom:0px;color:rgb(51,51,51);font-size:15px"><br></pre><pre class="gmail-m_6796607542332356564gmail-console-output" style="box-sizing:border-box;white-space:pre-wrap;margin-top:0px;margin-bottom:0px;color:rgb(51,51,51);font-size:15px">Regards,</pre><pre class="gmail-m_6796607542332356564gmail-console-output" style="box-sizing:border-box;white-space:pre-wrap;margin-top:0px;margin-bottom:0px;color:rgb(51,51,51);font-size:15px">Amar</pre><div><br></div>-- <br><div dir="ltr" class="gmail-m_6796607542332356564gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div></div>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-devel</a></blockquote></div>