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]
