Hi, This doesn't look like any UUID I ever encountered before:
7000009565bc370.f5330048ffa80212 I will ask the DBA if there is any way of generating those things with a stored procedure, but I don't expect a positive answer, to be quite honest. Greetings, Till Helge -----Ursprüngliche Nachricht----- Von: Russ Michaels [mailto:r...@michaels.me.uk] Gesendet: Mittwoch, 30. Januar 2013 11:36 An: cf-talk Betreff: Re: AW: Severe memory issue They will likely be a uuid, and most databases can also generate these natively too. Regards Russ Michaels www.michaels.me.uk www.cfmldeveloper.com - Free CFML hosting for developers www.cfsearch.com - CF search engine On Jan 30, 2013 10:34 AM, "Helwig, Till Helge" <till.hel...@saxsys.de> wrote: > > Hi, > > I would love to do that but unfortunately that's impossible. The guy > who designed the database layout all those years ago came up with the > idiotic idea of using unique OIDs (strings essentially) instead of IDs > in every table...and those OIDs have to be generated by some weird > class offered only by the framework the application has been > constructed with. Moving data about would be way better with INSERT > INTO ... SELECT ... or something, but sadly that's out of the question. > > Greetings, > Till Helge > > -----Ursprüngliche Nachricht----- > Von: Russ Michaels [mailto:r...@michaels.me.uk] > Gesendet: Mittwoch, 30. Januar 2013 11:31 > An: cf-talk > Betreff: Re: Severe memory issue > > > Have you tried moving this job off to th db server and taking cf out > of the loop. > Use stored procs etc. > > Regards > Russ Michaels > www.michaels.me.uk > www.cfmldeveloper.com - Free CFML hosting for developers > www.cfsearch.com- CF search engine On Jan 30, 2013 10:27 AM, "Helwig, > Till Helge" < till.hel...@saxsys.de> > wrote: > > > > > Hi, > > > > I'm working on a very old and very badly coded CF application at the > > moment. It contains servertasks that do a lot of batch processing > > where huge data sets are queried from a database, processed and the > > results written back to the DB. Unfortunately by now the jobs have > > become so large that we frequently get heap space errors. I'm trying > > to figure out why the process takes up so much memory and I've > > reached a point where I just don't know what to look for anymore. > > When looking at the memory monitor it looks to me like in every loop > > iteration he accumulated about 100 MB of data, procceses it and > > throws it away, but not entirely. A small piece stays in the memory > > every time and in the > end it clutters up all the heap space. > > > > What I already did: > > > > - Adding "var" to local variables > > > > - Replacing literals in queries with cfqueryparams > > > > - Replacing StructNew() at the beginning of loops with > > StructClear() > > > > - Replacing query-loops with index-loops > > > > I also started looking at dumps of the Java heap shortly before the > > process crashes, but I'm not really getting any wiser from that. I > > see that there are millions of objects in the memory and many of > > them are LoopTags and QueryTags, but other than that I have no idea > > what to make > of it. > > > > I've read that placing the code of the loop within its own thread > > might help, but that's impossible because our task already runs in > > its own thread and apparently CF can't spawn threads from within threads. > > > > If you have any ideas for me where to look for memory leaks, what > > else to try or an explanation for what might cause the problem, I > > would be really really thankful! > > > > Greetings, > > Till Helge > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:354119 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm