<div dir="ltr">I thought of hibernation, but then I loose the Timeout feature of the gen_server/gen_fsm. But of course I can do my own timers. I didn't go there yet. Will do the same and give my feedback if that improves the system or not.<div><br></div><div>Tks,</div><div>- Eranga</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 6, 2014 at 3:07 AM, Erik Søe Sørensen <span dir="ltr"><<a href="mailto:eriksoe@gmail.com" target="_blank">eriksoe@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Good advice. <br>
For the short term, I think the option of hibernating the processes should be mentioned as well - it ensures that dormant session processes don't take up more memory than necessary.</p>
<p dir="ltr">/Erik </p>
<div class="gmail_quote">Den 05/10/2014 23.18 skrev "Jesper Louis Andersen" <<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.com</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 5, 2014 at 9:27 AM, Eranga Udesh <span dir="ltr"><<a href="mailto:eranga.erl@gmail.com" target="_blank">eranga.erl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I found temporary variables, eg. binary_to_list of a XML data say 100 KB in size (Xmerl needs string), won't get freed for a long period of time without force garbage collection. Therefore when there are about 500 user sessions, each process consuming large memory blocks, makes the system memory usage extremely high. We plan to support a large number of user sessions, say 10000s and this memory consumption is a show stopper for us at the moment.</blockquote></div><br>Hi!</div><div class="gmail_extra"><br></div><div class="gmail_extra">This is your problem in a nutshell. Calling binary_to_list/1 on a 100KB binary blows it up to at least 2.4 megabytes in size. When the process is done, it takes a bit of time for the heap to shrink down again. It will just get into a serious problem when your system is going to process XML documents for a large set of users at the same time. You have two general options, which should both be applied in a serious system:</div><div class="gmail_extra"><br></div><div class="gmail_extra">* xmerl is only useful for small configuration blocks of data. If you are processing larger amounts of data, you need an XML parser which operates directly on the binary representation. In addition, if you can find an XML parser which allows you to parse in SAX-style, so you don't have to form an intermediate structure will help a lot. In Haskell, particularly GHC, fusion optimizations would mostly take of these things, but it doesn't exist in the Erlang ecosystem, so you will have to approach it yourself. Unfortunately I don't have any suggestion handy, since it is too long since I've last worked with XML as a format.</div><div class="gmail_extra"><br></div><div class="gmail_extra">* Your Erlang node() needs to have a way to shed load once it reaches capacity. In other words, you design your system up to a certain amount of simultaneous users and then you make sure there is a limit to how much processing that can happen concurrently. This frames the erlang system so it does not break down under the stress if it gets loaded over capacity. Fred Hebert has written a book, "Erlang in Anger"[0] which touches on the subject in chapter 3 - "Planning for overload". You may have 20.000 users on the system, but if you make sure only 100 of those can process XML data at the same time, you can at most have 240 megabytes of outstanding memory space at the moment. Also, you may want to think about how much time it will take K cores to chew through 240 megabytes of data. Reading data is expensive.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Irina Guberman (from Ubiquity networks if memory serves) recently had a very insightful (and funny!) talk[1] on how she employed the "jobs" framework in a situation which is slightly akin to yours. It is highly recommended, since she touches on the subject in far more depth than what I do here. For a production system I would recommend employing some kind of queueing framework early on. Otherwise, you system will just bow under the load once it gets deployed.</div><div class="gmail_extra"><br></div><div class="gmail_extra">[0] <a href="http://www.erlang-in-anger.com/" target="_blank">http://www.erlang-in-anger.com/</a></div><div class="gmail_extra">[1] <a href="https://www.youtube.com/watch?v=1Z_Z8aLIBQ8&list=UUQ7dFBzZGlBvtU2hCecsBBg" target="_blank">https://www.youtube.com/watch?v=1Z_Z8aLIBQ8&list=UUQ7dFBzZGlBvtU2hCecsBBg</a><br clear="all"><div><br></div>-- <br>J.
</div></div>
<br></div></div><span class="">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">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></span></blockquote></div>
</blockquote></div><br></div>