On 2005.01.24, Janine Sisk <[EMAIL PROTECTED]> wrote: > I did some experimenting over the weekend, and I have data to report, > though nothing terribly conclusive. [...] > > My observation is that both are growing, seemingly without bound, and > that they never give any memory back; even if one lets this sit > overnight with no activity, the memory footprint stays the same. > > I also discovered that I had a long-forgotten cron job which restarted > these sites weekly when they were running under 3.3+ad13. I have a > vague memory of this having been necessary due to a memory leak in 3.2, > which a number of us were having trouble with, and I just never took it > out. So this would have prevented us from noticing any similar > problems with 3.3. > > So, the problem may not be new in 4.x, but there is still a problem and > I'm still not sure what to do to track it down.
I'm starting to suspect that the "leak" is in application (Tcl) code, and not in the core AOLserver. I could be wrong, but signs are starting to really point in that direction. > The script that assembles the article for viewing, which is being > executed over and over, is pretty simple; it just selects a bunch of > data from the database, does an insert to track the fact that the > article has been viewed, and then returns the whole shebang to the > browser, formatted in the usual OpenACS way with an .adp template. > Nothing is being explicitly cached. Can you share the code with me so I can examine and review it? Are there any errors being thrown to the error log? If there's some memory cleanup steps towards the end of the script that aren't being executed because of an earlier uncaught Tcl error, that's a usual culprit in these kinds of problems. > I have not yet updated Tcl, and still plan to do that. So, you're running the same version of Tcl for your 3.3ad13 and the 4.0.8 builds? Does that mean you're running Tcl 8.3.2 with AOLserver 4.0.8? I'd strongly suggest building Tcl 8.4.9 with AOLserver 4.0.10 and seeing if that has any impact whatsoever on the memory growth. > What else can I do to help track this down? At this point, I think a code review is in order to identify if there's any places where the application could be using memory that never gets cleaned up or freed. If your application uses tDOM and you're not extra-careful about placing [catch]'es around blocks of code to ensure that the appropriate tDOM cleanup happens, this is a very common place for applications to leak memory. If you use NSVs and allow them to grow without bound, this is another common way to leak memory. Is there any way for you to share the code so that I can review it? -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
