Resource leak in graphics system?
Fri Aug 23 15:33:53 CEST 2002
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
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?
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
>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.
More information about the erlang-questions