I too thought of setting a cron job to restart the server once per day in order to keep the memory "fresh".
In a production environment, are there any downsides to doing this, i.e., server inaccessibility, etc..? Thanks. Gregory At 08:25 AM 5/20/2002 -0400, you wrote: >It is more an issue of it being worth tracking down a small memory >leak vs a large memory leak. Our software still has some very small >leaks, on the order of 10kv every hour... it would probably take us a >month to track down and solve all these problems. I find it easier to >restart the web servers daily. > >We did have some enourmous leaks as well, based on circular reference, >and those ate up 1 GB of memory in about 30 minutes... It took us >about three weeks to find it. > >Gregory Matthews writes: > > So am I being overly paranoid concerning the "leak" potential of mod_perl > > programming? > > > > If I start with "strict" code to begin with and try my best to stay away > > from the problems you mentioned, then any potential memory leak/drain > > issues will be avoided? > > > > Keep in mind, although my application is not designed to launch the space > > shuttle, I do want it to be solid/stable/peformance-packed from the > ground up. > > > > I will be also be using MySql with the Apache::DBI module. > > > > Thanks in advance. > > > > Gregory > > > > > > At 11:34 PM 5/19/2002 -0400, you wrote: > > > > I have a couple of questions regarding leaking memory in mod_perl: > > > > > > > > 1. What are the main culprits, in order of severity, of memory leaks, > > >i.e.: > > > > > > > > a. global variables (NOT lexically scoped via my) > > > > b. ... > > > > c. ... > > > > > > > > 2. When writing code from scratch (a new application), what is the > > >best > > > > way to avoid creating leaks to begin with, i.e., use strict;, PerlWarn > > >On, > > > > etc.. ? > > > > > >There are actually not very many ways you can leak memory in Perl (and > > >thus mod_perl). Most people confuse memory growth with memory leakage. > > >If you want to know how to avoid memory growth, look at the performance > > >tuning stuff in the Guide, like passing references, avoiding slurping of > > >large files, controlling the buffering of DBI result sets, etc. > > > > > >Leaks are caused by circular references, the string form of eval (at > > >least it used to leak a little), nested closures (sometimes created > > >accidentally with the Error module), and one or two obscure syntax > > >problems. I think one of them involved code like "my $x = 7 if $y;". > > >Matt Sergeant got bitten by this in the early stages of AxKit > > >development, and the details are in the mailing list archive. > > > > > >Global variables by themselves are not a source of leaks or growth. If > > >you slurp a large file into a global, your process will grow, but the > > >same is true for a lexical. > > > > > >- Perrin > > > > > >-- >C Wayne Huling <[EMAIL PROTECTED]>
