<div dir="ltr">Thank you Mahesh.<div><br></div><div>I even have a <font face="monospace, monospace">fullsweep_after 0</font> in the router process, even though it is literally never touching the data: the router API will lookup an element in a router ETS table, and will immediately send the data to that process - without being sent to the router itself.</div><div><div class="gmail_extra"><br></div><div class="gmail_extra">The swapping seems an interesting option and has also been suggested here above. Not sure how easily it can be done.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 23, 2015 at 10:09 AM, Mahesh Paolini-Subramanya <span dir="ltr"><<a href="mailto:mahesh@dieswaytoofast.com" target="_blank">mahesh@dieswaytoofast.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">In our case, a key insight is something Robert mentioned earlier.  <div>To paraphrase it, "Your memory is not going to be reclaimed till *every* process that touched it has either been GC'd, or sleeps with the fishes".</div><div>And our code had a few router processes that, quite literally, did nothing but pass binaries on from point A to point B - no reason to worry about *those* right?  (hint: wrong)<br><div><br><div>In the short run, walking the process chain and doing full-sweeps on *every* process that might (!!!) touch the binary.  (we did that)</div><div>In the longer run, see if you can swap out the routing processes with versions that respawn themselves in some form or the other (we did that too. eventually. was harder)</div></div></div><div><br></div><div>Cheers</div></div><div class="gmail_extra"><div><div class="h5"><br></div></div></div></blockquote></div></div></div></div>