<div>Yes, the server side shell has collapsed.</div>

<div>I will analyse all of your points.</div>

<div>Thank you very much for your reply.<br>-- <br>with regards,<br>S.Surindar <br> </div>

<div><span class="gmail_quote">On 09 Jun 2006 10:46:59 +0200, <b class="gmail_sendername">Raimo Niskanen</b> <<a href="mailto:raimo@erix.ericsson.se">raimo@erix.ericsson.se</a>> wrote:</span>

<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">In erts-5.4.8 (R10B-6) there was a fix for larger heap sizes:<br><br>   OTP-5596  In the hipe application, there's a new experimental register

allocator (optimistic coalescing), and the linear scan              register allocator is now also available on ppc. Plus lots of              cleanups.              Minor hybrid heap corrections.

<br><br>             The maximum size of a heap used to be articially limited so<br>             that the size of a heap would fit in 28 bits; that limitation<br>             could cause the emulator to terminate in a garbage collection

even if there still was available memory. Now the largest              heap size for a 32 bit CPU is 1,699,221,830 bytes. (Thanks to              Jesper Wilhelmsson.)              Also removed the undocumented +H emulator option.

<br><br>But do you need larger heap sizes or fixing your application?<br><br>There is a gotcha concerning the shell history. The shell<br>keeps a history of commands and results, and since<br>the shell has references to this data, it is not

<br>garbage collected. Might this be a problem?<br><br>Or is it simply so that you have a non-tail recurisive loop<br>that is eating your memory?<br><br>You can use top (the unix command) to see if the server<br>side emulator grows gradually, or explodes suddenly,

<br>which size it starts on and so on, and this may give<br>you some clue.<br><br><a href="mailto:surindar.shanthi@gmail.com">surindar.shanthi@gmail.com</a> (Surindar Sivanesan) writes:<br><br>> I'm using Eralng emulator version is  

5.4.3. > The type of application is load testing with simulator in one PC ( which has > multiple thread. At that monent we have 200 threads) which sends requests to > the server in another PC. > The Shell running as server is collapsed.

<br><br>Do you mean that the server side shell process is the one that<br>memory exploded and caused the emulator to crash?<br><br>><br>> -with regards,<br>>  S.Surindar<br>><br>><br>> On 09 Jun 2006 09:04:31 +0200, Raimo Niskanen <

<a href="mailto:raimo@erix.ericsson.se">raimo@erix.ericsson.se</a>> > wrote: > > > > Well first the standard questions: > > * What is the Erlang/OTP release, or emulator version > > erlang:system_info(system_version)?

<br>> > * What is the application, or what kind of application is it?<br>> ><br>> > When the emultor starts it pre-calculates the heap sizes<br>> > to use and puts them in an array. The calculated heap sizes

<br>> > are up to ridiculouosly large sizes, so that if you would<br>> > need such large heaps you most probably have other problems.<br>> ><br>> > You most probably have other problems.<br>> >

<br>> > Your emulator has allocated 578 Mbytes of memory and had<br>> > a gigantic process heap for one process. That process<br>> > must have eaten all memory. The question is if the<br>> > emulator is leaking memory or if your application

<br>> > allocates memory that can not be reclaimed in a<br>> > garbage collection?<br>> ><br>> > So, more info is needed.<br>> ><br>> > And, there has been releases with a wee bit to small

> > pre-calculated heap sizes. > > > > Locate the culprit process in the crash dump viewer and > > try to find out what it is doing. Perhaps look at the > > call stack. That may give something.

<br>> ><br>> ><br>> ><br>> > <a href="mailto:surindar.shanthi@gmail.com">surindar.shanthi@gmail.com</a> (Surindar Sivanesan) writes:<br>> ><br>> > > Dear all,<br>> > > I'm running an Erlang application.

> > > After 12 hours, the erlang shell crashes with *Abnormal termination.* > > > Then i have viewed the Erlang dump in the *Crash dump viewer*. > > > The crash dump viewer has the following information.

<br>> > ><br>> > > Slogan*:  no next heap size found: 148185174, offset 0.*<br>> > > Memory allocated: 606002043 bytes.<br>> > > Atoms : 7158.<br>> > > Processes : 703<br>> > > ETS tables : 45

<br>> > > Funs : 442<br>> > ><br>> > > Please give me the reason for this crash.<br>> > ><br>> > ><br>> > > with regards,<br>> > > S.Surindar<br>> ><br>

> > --<br>> ><br>> > / Raimo Niskanen, Erlang/OTP, Ericsson AB<br>> ><br>><br>><br>><br>> --<br>> with regards,<br>> S.Surindar<br><br>--<br><br>/ Raimo Niskanen, Erlang/OTP, Ericsson AB

<br></blockquote></div><br><br clear="all"><br>