If you don't want to restart the server then don't.... do this instead, it should help prevent small leaks from being a problem. http://httpd.apache.org/docs-2.0/mod/mpm_common.html#maxrequestsperchild
----- Original Message ----- From: "Per Einar Ellefsen" <[EMAIL PROTECTED]> To: "Gregory Matthews" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, May 20, 2002 3:30 PM Subject: Re: Memory Leaks > At 23:23 20.05.2002, Gregory Matthews wrote: > >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)? > > And if something goes wrong? You'd be having a server offline with noone > knowing about it. > > >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]> > > > > > > -- > Per Einar Ellefsen > [EMAIL PROTECTED] >
