Have you tried the #erlang IRC channel on Freenode? You'll probably find a lot of Erlang developers there.<div><br></div><div>Juanjo<br><div><br><br><div class="gmail_quote">On Thu, Jun 23, 2011 at 10:57 PM, Andy W. Song <span dir="ltr"><<a href="mailto:wsongcn@gmail.com">wsongcn@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Thanks for the suggestions. I left the machine for more than 10 hours and the figures didn't change. <div><br></div>
<div>I'm out of ideas. How can I approach to experts in stead of passively waiting on the mailing list?</div>

<div><br></div><div>Thanks</div><div>Andy<div><div></div><div class="h5"><br><br><div class="gmail_quote">On Thu, Jun 23, 2011 at 8:38 PM, Jesper Louis Andersen <span dir="ltr"><<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@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>On Thu, Jun 23, 2011 at 05:39, Andy W. Song <<a href="mailto:wsongcn@gmail.com" target="_blank">wsongcn@gmail.com</a>> wrote:<br>



<br>
> The figures in red are provided htop, others are output of memory() call<br>
> from erlang shell. Please look at the total and erlang residence memory.<br>
> When there is no connection, these two are roughly same, with 100K<br>
> connections, residence memory is a little larger than total, with 200K<br>
> connections, residence memory is almost double the total.<br>
> Can anybody explain?<br>
<br>
</div>The first thing I would analyze in this situation is memory<br>
fragmentation obtained from the underlying memory allocation. If the<br>
memory fragments, then surely you can see stuff like this happening<br>
where your resident set size will be larger. I would definitely start<br>
out by setting the spotlight on the underlying allocator or the<br>
allocation pattern because as you see, there is no discrepancy if you<br>
ask the Erlang VM about its view on the matter. What speaks against<br>
fragmentation is the very young life of the program. Fragmentation<br>
problems usually only show up in long-running programs where pointers<br>
are set in stone (making compaction impossible).<br>
<br>
Another option is that there is some auxiliary data structure in the<br>
Erlang VM which are grown up in between the 100K and 200K connection<br>
count. If the structure is accessed randomly, then surely all the<br>
Virtual Memory pages will get allocated and assigned to the process,<br>
increasing the RSS of the program.<br>
<br>
It is also interesting to look for what happens if you simply ignore<br>
the program for a bit of time. Perhaps the allocated memory is not<br>
released right away, but over time.<br>
<br>
Apart from my ideas, I am afraid you will need an Erlang VM expert<br>
with more intrinsic knowledge than me.<br>
<br>
<br>
--<br>
<font color="#888888">J.<br>
</font></blockquote></div><br><br clear="all"><br></div></div>-- <br><div>---------------------------------------------------------------</div><div>有志者，事竟成，破釜沉舟，百二秦关终属楚</div><div>苦心人，天不负，卧薪尝胆，三千越甲可吞吴</div><br>
</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></div>