<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 1, 2019 at 11:11 AM Frank Muller <<a href="mailto:frank.muller.erl@gmail.com">frank.muller.erl@gmail.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"><br style="color:rgb(49,49,49);word-spacing:1px"><span style="color:rgb(49,49,49);word-spacing:1px;background-color:rgb(255,255,255)">2. Hibernating the process after processing N packets (varying N=10..128).</span><br style="color:rgb(49,49,49);word-spacing:1px"><span style="color:rgb(49,49,49);word-spacing:1px;background-color:rgb(255,255,255)">The HIT rates went above 90% immediately.</span><br style="color:rgb(49,49,49);word-spacing:1px"><a href="http://147.135.36.188:3400/observer_cli_AFTER.jpg" rel="noreferrer" style="font-size:1rem;word-spacing:1px" target="_blank">http://147.135.36.188:3400/observer_cli_AFTER.jpg</a><br style="color:rgb(49,49,49);word-spacing:1px"><br style="color:rgb(49,49,49);word-spacing:1px"><span style="color:rgb(49,49,49);word-spacing:1px;background-color:rgb(255,255,255)">What is the effect of hibernating this process on the long term? </span><br style="color:rgb(49,49,49);word-spacing:1px"><span style="color:rgb(49,49,49);word-spacing:1px;background-color:rgb(255,255,255)">This process is receiving about ~1200 packets/sec under normal load and can reach ~3000 packets/sec under heavy load.</span><br style="color:rgb(49,49,49);word-spacing:1px"><br style="color:rgb(49,49,49);word-spacing:1px"><span style="color:rgb(49,49,49);word-spacing:1px;background-color:rgb(255,255,255)">Is there a better way of solving the problem by tweeting the bin allocator SBC/MBC?</span><br style="color:rgb(49,49,49);word-spacing:1px"><span style="color:rgb(49,49,49);word-spacing:1px;background-color:rgb(255,255,255)"></span></blockquote><div><br></div><div>So hibernation will do a few things:</div><div><br></div><div>- a full-sweep garbage collection</div><div>- drop the stack</div><div>- memory compaction on the process.</div><div><br></div><div>Unless specified otherwise, a call to `erlang:garbage_collect(Pid)` forces a major collection so it may look like what you have is more or less a case of a process spiking with a lot of memory, and then becoming mostly idle while still holding enough references to refc binaries to not GC old data. Rince and repeat and you get a lot of old stuff.</div><div><br></div><div>Fragmentation of this kind is often resolved with settings such as `+MBas aobf +MBlmbcs 512` being passed to the emulator, which changes the allocation strategy for one that favors lower addresses, and reduces the size of a multiblock carrier to use more of them. The objective of this being to reuse existing blocks and make it easier to deallocate some by reducing the chance some binary keeps it active. <br></div><div><br></div><div>If what you have is really one process though, you may get better results by running some hibernation from time to time, but only experimentation will confirm. If the allocator strategies don't cut it (or can't be used because you want to keep the 5 years live upgrade streak going), do something like count the packets you received, and every N of them (pick a large value so you might run a compaction once every 10 minutes or so; you can pick based on the leaking rate), force a hibernation to shed some memory.<br></div><div><table class="gmail-highlight gmail-tab-size gmail-js-file-line-container"><tbody><tr><td id="gmail-LC7" class="gmail-blob-code gmail-blob-code-inner gmail-js-file-line">
</td>
      </tr>
      <tr>
        </tr></tbody></table><table class="gmail-highlight gmail-tab-size gmail-js-file-line-container"><tbody><tr><td id="gmail-LC8" class="gmail-blob-code gmail-blob-code-inner gmail-js-file-line"><br></td></tr><tr></tr></tbody></table></div></div></div>