<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 2, 2014 at 7:31 AM, Max Lapshin <span dir="ltr"><<a href="mailto:max.lapshin@gmail.com" target="_blank">max.lapshin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">
<span style="font-family:arial,sans-serif;font-size:13px">Before I've added this problem was not only with memory usage. When server allocated 12 GB RAM, it was performing very badly.</span></div>
<div class="gmail_extra"><br></div></div></blockquote><div><br></div><div>When you say performing badly, how do you notice this? increased latency? CPU load?</div><div><br></div><div>I assume that is quite hard to setup a test system that replicates the behaviour?</div>
<div><br></div><div>If it is not possible to simulate the problem a couple of additional measurements that would be helpful are:</div><div><br></div><div>1) Saving recon_alloc snapshots at regular intervals (every minute maybe) up until the system reaches the bad state. It should not add a noticeable overhead to the system, and is something I recommend most people to do anyways if this kind of thing were to happen. </div>
<div>2) Sending me a core file generated by either kill -ABRT $PID or through gdb <a href="https://sourceware.org/gdb/onlinedocs/gdb/Core-File-Generation.html">https://sourceware.org/gdb/onlinedocs/gdb/Core-File-Generation.html</a>, and the beam.smp (erts-6.0/bin/beam.smp) that you are running. </div>
<div><br></div><div>We have a couple of ideas about what could cause the mbcs pool to behave this way, but can of course not be sure until we test the potential solutions. We would probably also need your help with testing when we have a solution in place as this is a behaviour we have not been able to reproduce in our tests.</div>
<div><br></div><div>Lukas</div></div></div></div>