<div dir="auto">The erlang vm has it's own memory allocators (carriers) they usually create a small memory overhead. I've seen them consuming exorbitant amounts of memory before, likely because of memory fragmentation. Their usage is not reported in the erlang virtual memory stats by default but you can check them explicitly.<div dir="auto"><br></div><div dir="auto">When fighting with memory fragmentation I created this script to show the current carrier overhead: (waste) <a href="https://gist.github.com/dominicletz/615e4b89b9e6f2059b2520ed9adac5dc">https://gist.github.com/dominicletz/615e4b89b9e6f2059b2520ed9adac5dc</a></div><div dir="auto"><br></div><div dir="auto">My solution in the end was to upgrade OTP to a newer version. And it made the crazy overheads go away.</div><div dir="auto"><br></div><div dir="auto"> Cheers!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Max Lapshin <<a href="mailto:max.lapshin@gmail.com">max.lapshin@gmail.com</a>> schrieb am Do., 23. Sep. 2021, 08:42:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>You show a strange graphic without any numbers. all other commands are also cutted.</div><div><br></div><div>Also part of your email is rather unclear: you write to a public list that your email is confidential. Bad idea.</div><div><br></div><div>About memory: </div><div><br></div><div>1) use recon in your production. recon_alloc will help to collect big amount of information from erlang runtime</div><div>2) take a look at <span style="font-variant-ligatures:no-common-ligatures;color:rgb(0,0,0);font-family:Menlo;font-size:14px">/proc/3975367/maps, </span>sometimes it helps to find leaks or better interpret numbers.</div><div><br></div><div>What you see is a mismatch between different ways to calculate memory. Usually it is ok to live with such a difference.</div><div><br></div><div><br></div>





</div>
</blockquote></div>