Hmm... How are you building the xml doc? If you are appending to it 10 times and not using Java, I believe it creates a new variable every time you append (and most likely it won't be GC'ed until your script has finished running).
Calling the GC directly will not always have an effect, as it's not a command but more of a suggesting to the GC to do garbage collection. There are certain flags you can turn on in your config file for the jdk, something like ++AggressiveGC I believe, but I'm not sure if that will help you out. If you are building the string inefficiently, try optimizing that. You also might want to put in a few sleep calls to allow the GC to run. (I've never tried this, but it just might work). Russ > -----Original Message----- > From: Ryan, Terrence [mailto:[EMAIL PROTECTED] > Sent: Monday, September 11, 2006 12:01 PM > To: CF-Talk > Subject: RE: CF Memory problems? > > Is debugging on the server turn on at all? > > Even if the page is set to not show debugging it is still being collected. > If you are doing many function calls with the loop, they all get thrown > into the debugging info too. Which will then eat up memory, but be very > hard to detect. > > But this theory depends on debugging being turned on. > > Terrence Ryan > Senior Systems Programmer > Wharton Computing and Information Technology > E-mail: [EMAIL PROTECTED] > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, September 11, 2006 11:28 AM > To: CF-Talk > Subject: CF Memory problems? > > I have a CFMX script that continually comes close (and sometimes succeeds) > in eating up all of the CFMX sever's memory. I've put tracking code in > various places to watch the memory stats (using calls to > CreateObject("java","java.lang.Runtime").getRuntime() ). I've also tried > running (while this script is executing) another page that uses the > runtime.gc() call to force a garbage collect, which only has a negligable > effect on the memory usage. I can run this on a testing server, to be > sure that some other script isn't the real culprit, but see the same > results. > > Here is what the script does: > > Run a query to determine which accounts need processing > > Loop over that query (usually about 300 records): > 1. Build a 10 line XML doc. Use the same var name for this doc everytime > 2. CFHTTP that doc to a website/service, get another XML doc back. > 3. XMLParse the returned doc > 4. Create a Query var, using the same var name everytime > 5. Loop over the parsed XML doc, creating a row in the Query var with > about 20 calls to QuerySetCell for each pass over the XML doc. > 6. Loop over the Query structure created in step 5, and do 3 CFQUERY > INSERTs to a various tables > > That's it! Note that for each iteration through the main loop I already > know how many records will be returned from the website I'm HTTPing to, > and I throttle it to only return 200 at a time (ie, I might make multiple > passes through steps 1-5 whenever I know that there are more than 200 > records to be returned. > > Note also that I'm still trying to figure out why this was written to even > create the intermediate query to begin with (instead of just looping over > the XML doc to do the database inserts). > > Are there any known problems with creating the same query var over and > over? Or creating the same XML doc over and over? > > I've seen this problem with memory being eaten up when I execute a QoQ > with the same name over and over (around 1000 times or more), and got > around that by using array and list functions instead QoQ table lookups. > > If this were a "normal" memory problem then I'd expect the periodic calls > for a garbage collection to help out, but like I said, those calls are > having just about 0 effect. > > I'm running the latest CFMX update, and have upped the maxmem for JVM to > 1200. > > I'm going juts on this one, since the script is pretty simple and > straightforward - just a lot of looping! I'm looking at trying to break > it up, but that's going to take some time. > > TIA! > Reed > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:252754 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
