Resource leak in graphics system?

Peter-Henry Mander erlang@REDACTED
Fri Aug 23 15:33:53 CEST 2002


Thanks Håkan,

I solved the "problem" by disabling the Event Trace. I've made a note of 
what you said, but at this stage of the project, I'm relying less and 
less on ET, so I may leave it out in future.

I'm now attempting to minimise variations in the callflow rate between a 
Media Gateway Controller and a Media Gateway. What I call a callflow is 
a series of Megaco transaction such as add, modify and subtract-all. The 
rate fluctuates between 200 and 350 per second, which isn't bad (I 
think). It may simply be caused by respawning processes instead of 
reusing them, causing unnecessary garbage collection. I'm still 
investigating this...

Megaco performance-testing equipment I've looked at can achieve max 
500/sec with dedicated hardware, but it lacks the flexibility I require. 
If I can achieve 300+ sustained using Erlang, I'll be sooooo pleased!

The documentation mentions that the MGC may be implemented to run as 
distributed nodes, it looks as if this is the way for me to go. Do you 
know how much speed improvement can be achieved this way?

Pete.

Hakan Mattsson wrote:

>On Fri, 23 Aug 2002, Peter-Henry Mander wrote:
>
>Pete> I've a query about the memory usage of the graphics system which appears 
>Pete> to grow without end! The offending processes are gs_frontend, gstk, and 
>Pete> et_viewer. Is there something I ought to be doing to plug what appears 
>Pete> to be a resource leak? Is there a simple way I can ensure that a node 
>Pete> will not employ any graphic system? Is this a known "feature" of Erlang/Tk?
>
>Do you have lots of events in your et_viewer canvas?
>How big is the et_viewer process?
>How big is the et_events table?
>
>If you are viewing large amounts of trace data, the et_viewer tool can
>grow quite big (hundreds of megabyte).  It should not not grow without
>end though.
>
>You may consider to use the max_events option of et_viewer, to limit
>the internal cache of the tool. Instead of having a huge canvas with a
>scrollbar, the max_events can be used to obtain a small canvas and
>instead scroll with the f/p/l/n/r keys. In this way the number of
>graphical objects will be much lesser.
>
>/Håkan
>
>
>
>






More information about the erlang-questions mailing list