FMS application core eating 3 Gb per 24 hours

Forum|Forum|19 years ago
November 24, 2006
5 replies
542 views

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 ?

This topic has been closed for replies.

A

Anonymous

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 !

A

Anonymous

...specifically:

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

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

A

Anonymous

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

A

Anonymous

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.

A

Anonymous

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.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded