Unfortunately, we only have one machine. If we did employ the cron job as a clean-up utility once per day, wouldn't the potential impact of a site being unavailable only be for a few seconds (until Apache restarted)?
Gregory At 05:12 PM 5/20/2002 -0400, you wrote: >Like another suggestion, we have a cluster of machines and roll the >restarts every hour. Each machine is offset but 10 minutes. > >Gregory Matthews writes: > > 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]> > > > > > >-- >C Wayne Huling <[EMAIL PROTECTED]>
