macromedia flash flashcom: 1. FMS is installed on a P4 3 Ghz cpu and 4 Gb memory
2. FMS is running in the 'application-scope' ; each application (main.asc) has
it's own core
3. both applications create +/- 30-60 instances (lets name them chat-rooms)
and those get abandoned when they are empty (they get removed by the idle or
garbage collector after 5 minutes in case no clients are in the instance any
more)
4. About 100-250 connections are in use, divided over 2 applications and about
40 active instances
5. We call in every instance for every user every 20 seconds an PHP script
using the XML.load method which validates the connected user (obj_xml = new
XML() ; obj_xml.load("phpscript.php"); obj_xml.onLoad = checktheaccessetc ;
delete obj_xml)

However using this setup both applications start with 0 Kb memory usage and
have grown to monsters, eating up to 3 Gigabyte of memory each. When the size
reaches approx. 3072 Kb of memory the core crashes and it sometimes takes down
the FMS master-service too resulting in rejected connections for ALL current
and new users to both applictions (!)

I think that's a serious memory-leak. (+/- 3072/24 = 150 Megabytes per hour).
We've made a graphic of the memory-usage and it shows a straight line from the
start (0 Kb) to 3 Gb of memusage after about 24 hours.

One application uses a shared-memory-object on the server (NOT persistent) the
other does not. Both applications use the XML object to load a php-script. (see
above).

Is anyone familiar with this crazy use of memory by FMS and knows how to deal
with it, besides restarting the FMS service every 12-24 hours to prevent a
lockup ?

bump. It's a pity that a core process crashes when it reaches 3072 Kb (=3 Gb)
of memory usage, but how can we avoid this huge memoryleak in our 'pretty
normal' application ?

Is the declaration of a new XML() object inside the onConnect function a
problem ? We delete this object inside the xml.onLoad function, to be sure.

bump.

We've removed the loading of external scripts using the XML() object
(xml.load(url)). We're now using the good old sendAndLoad() method and
Loadvars().

Even this method is leaking memory like *ell. We execute (stresstest) 2-3
loadvars per second for some time and the FMS core for that application (scope:
app) is eating up 50 to 150 Kbytes of memory per second (!)

The external script returns about 15 variables, all strings, no bigger than
1200 characters total. We deleted all objects inside all functions (using code
like this:

my_lv_in = new Loadvars();
my_lv_out = new Loadvars();
...
my_lv_out.onLoad = function(sts) {
trace( my_lv_in.toString(); );
my_lv_out = null; // clean up
delete my_lv_out; // clean up more
delete my_lv_in; // total cleanup !
}
...
my_lv_out.sendAndLoad("myurl.php", my_lv_in, "GET");
...

But guess what ; FMS still leaks memory. If we do NOT call those loadvar
methods we do not leak memory. So the problem is inside the loading of external
data.

The problem is with the FMS Garbage collector. It seems to use reference count
which means that if you create a circle reference - ie an object holds a
reference to your LoadVars and vice versa, they both are referenced and so none
will be deleted. We had this problem with xml. What we did was:

1. Make sure that all data loaded are deleted as soon as they are used. Use
delete and set references to null.
2. Try to clear all references between objects used in the data load process -
again go nuts with delete and =null.
3. The GC doesn't seem to kick in when you want it. Create a counter that's
incremented with each data load and when you reach an arbitrary number (like
50) run application.gc() to force garbage collection.
4. If nothing else works, restart the app every now and then. By using the
above techniques you should buy yourself at least a weeks extra running time.

/Johan
http://www.man-machine.se

....specifically:

The my_lv_out.onLoad should be deleted and set to null.

/Johan

Thanks, I wasn't sure if I was walking the right direction with the deleting
and setting to null (it sounds a bit 1990 to be honest) and I never suspected
that I needed to manually run a GC but if that's what needed then that's what
is going to be done. I'll keep you (all) informed !