<div dir="ltr"><div><div><div><div><div>Hello Max,<br><br></div><div>You have forgot to mention which version of Erlang/OTP you are running. Things have changed quite a bit in the last releases of Erlang on this front.<br>
</div><div><br></div>You can get a lot of information about what is actually allocated by looking at erlang:system_info(allocator) and erlang:system_info({allocator,Alloc}). And this information can guide you in you decision of what flags you might want to set. <br>
<br></div><div>In your case it sounds like maybe you end up allocating a lot of sbcs (single block carriers) instead of getting mbcs (multi block carriers). You can check this by looking at the mbcs and sbcs section in the info you get from erlang:system_info({allocator,$type_alloc}). If you notice you have a lot of sbcs you might want to raise the threashold for when a sbc is used, +MB<strong><a name="M_sbct"><span class=""></span></a></strong>sbct 1024. <br>
</div><div><br>You might want to look at if the calls section in any allocator has almost as many to $type_alloc as it does to mseg_alloc. eg:<br><br>1> erlang:system_info({allocator,binary_alloc}).<br>[{instance,0,<br>
           [{versions,"0.9","3.0"},<br></div> -- snip --<br>           {calls,[{binary_alloc,0,77},<br>                    {binary_free,0,76},<br>                    {binary_realloc,0,0},<br>                    {mseg_alloc,0,3},<br>
                    {mseg_dealloc,0,2},<br>                    {mseg_realloc,0,0},<br>                    {sys_alloc,0,0},<br>                    {sys_free,0,0},<br>                    {sys_realloc,0,0}]}]}]<br><br></div>
We can in the above see that there were 77 calls to binary_alloc and we did 3 mseg_alloc. One mseg_alloc roughly corresponds to a mmap (there is also a mseg cache, so the actual number of mmaps could be less). By playing with sbct and maybe mmbcs (this sets a static mbc that is allocated and kept from though out the lifetime of the beam) you could get better statistics. Note that IIRC mmbcs only works for mbcs so make sure that it is mbcs objects which you are allocating before twiddling with it. <br>
<br></div>Yet another idea could be to play with the mseg cache parameters, MMamcbf, MMrmcbf and MMmcs. By making the cache keep more carriers you could up the cache hit rate and thus reduce mmaps.<br></div><div><br></div>
Lukas<br><div><div><div><div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 14, 2013 at 3:41 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Right now I fight with problem of streaming 10 Gbit/s of video and more from single server.<div><br></div>
<div>I have met different problems (mostly about locking into single process like with file:read_file), </div>
<div>but right now I have one question, it is about memory allocation.</div><div><br></div><div>I've started strace against one of threads running scheduler and saw that it makes lot of mmap/munmap.</div><div><br></div>

<div>For example during second 1376487042 it has called mmap 72 times with sizes 1052672, 2101248.</div><div><div><br></div><div>Such lines are very interesting for me:</div><div><br></div><div>1376487042.167246 mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe8f49bf000</div>

<div>1376487042.174690 munmap(0x7fe90c6ff000, 1052672) = 0</div><div><br></div></div><div><br></div><div>erlang asked system for one megabyte of memory and after 7 milliseconds returned it back.</div><div><br></div><div>
To make it clear: erlyvideo is reading 700-800 megabytes per second from several hard drives, repack them a bit and sends to network via TCP sockets.</div>
<div><br></div><div><br></div><div><br></div><div>It is possible to tell erlang that it can use 20GB or 30 GB or ram and don't return it back at all?</div><div><br></div><div>I suppose that such often allocation/deallocation leads to high cpu usage of process kswapd0 that (perhaps) tries to do something with such big amount of freed pages.</div>

<div><br></div><div>I have looked at erts_alloc.html page. Well, it is scary a bit, just like when I've looked into the airplane cabin. Should I change any options from this page or I shouldn't touch memory allocator at all?</div>

<div><br></div><div><br></div></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>