On Mon, 20 May 2002 16:23:40 -0500
Gregory Matthews <[EMAIL PROTECTED]> 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 rest
Gregory Matthews wrote:
> Does using the Apache::GTopLimit module have the same net effect as
> restarting the server itself by simply killing off the actual processes
> which are growing beyond the set threshold, and thereby causing new
> processes to be born?
It's not the exactly the same, s
Per Einar Ellefsen wrote:
> At 23:54 20.05.2002, Allen Day wrote:
>
>> I've noticed that if I restart apache while I'm in the middle of a
>> download (MP3 stream), after the buffer in my MP3 player runs out, it
>> skips to the next track -- presumably because the connection was closed.
>>
>> This
At 00:45 21.05.2002, Issac Goldstand wrote:
>I'd like to try to disagree here. I have built several file-related
>webapps where I have implemented virtual filesystems which require special
>perl modules to access the files at all. mod_perl takes care of serving
>the requests. If I need a res
Does using the Apache::GTopLimit module have the same net effect as
restarting the server itself by simply killing off the actual processes
which are growing beyond the set threshold, and thereby causing new
processes to be born?
Gregory
At 03:27 PM 5/20/2002 -0700, you wrote:
>On Mon, 20 May
I'd like to try to disagree here. I have built several file-related
webapps where I have implemented virtual filesystems which require
special perl modules to access the files at all. mod_perl takes care of
serving the requests. If I need a restart, then I can still safely use
graceful. Ad
On Mon, 20 May 2002, Perrin Harkins wrote:
> Apache::SizeLimit or Apache::GTopLimit is a better way to do it, since
> it results in fewer unnecessary restarts. However, it's still a good
> idea to restart periodically, because some of the shared memory seems to
> become unshared over time no
I mentioned the connection closing as a drawback of restarting the server
-- it was slightly OT for the thread.
Yes, it is a subclass of Apache::MP3 that can stream video and audio.
There is an old version called Apache::Jukebox in the Apache::MP3 CVS at
namp.sourceforge.net in case anyone is int
Jason wrote:
> 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
Apache::SizeLimit or Apache::GTopLimit is a better way to do it, since
it r
At 23:54 20.05.2002, Allen Day wrote:
>I've noticed that if I restart apache while I'm in the middle of a
>download (MP3 stream), after the buffer in my MP3 player runs out, it
>skips to the next track -- presumably because the connection was closed.
>
>This might cause a problem for you if your u
Per Einar Ellefsen wrote:
> And if something goes wrong? You'd be having a server offline with noone
> knowing about it.
You can easilly set up mon (http://www.kernel.org/software/mon/) to page
you if the server doesn't come back up within a certain amount of time.
- Perrin
I've noticed that if I restart apache while I'm in the middle of a
download (MP3 stream), after the buffer in my MP3 player runs out, it
skips to the next track -- presumably because the connection was closed.
This might cause a problem for you if your users are downloading big
files. They might
On Monday 20 May 2002 9:30 pm, Gregory Matthews wrote:
> 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..?
It's very rare to h
ROTECTED]>
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
&
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?
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, w
Gregory Matthews wrote:
> 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..?
There have been some discussion on the list abo
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 o
On Mon, 20 May 2002, Mark Fowler wrote:
> On Mon, 20 May 2002, Matt Sergeant wrote:
>
> > if ($@ && $@->isa('Exception::DB')) {
> >debug "Exception: $@";
> >$um->dbh->rollback;
> > }
> >
> > (note: if you expect all exceptions to be references like this, you had
> > better have a $SIG{__D
On Mon, 20 May 2002, Matt Sergeant wrote:
> if ($@ && $@->isa('Exception::DB')) {
>debug "Exception: $@";
>$um->dbh->rollback;
> }
>
> (note: if you expect all exceptions to be references like this, you had
> better have a $SIG{__DIE__} handler installed to bless non-blessed
> exceptions
On Mon, 20 May 2002, F. Xavier Noria wrote:
> On Mon, 20 May 2002 10:15:02 +0100 (BST)
> Matt Sergeant <[EMAIL PROTECTED]> wrote:
>
> : > my $um = UserManager->new;
> : > # ...
> : > try {
> : > $um->write_user($user);
> : > $um->dbh->commit;
> : > } catch Exception::DB
On Mon, 20 May 2002 10:15:02 +0100 (BST)
Matt Sergeant <[EMAIL PROTECTED]> wrote:
: > my $um = UserManager->new;
: > # ...
: > try {
: > $um->write_user($user);
: > $um->dbh->commit;
: > } catch Exception::DB with {
: > my $e = shift;
: > debug "Excepti
On Mon, 20 May 2002, F. Xavier Noria wrote:
> On Sun, 19 May 2002 23:34:24 -0400
> "Perrin Harkins" <[EMAIL PROTECTED]> wrote:
>
> : 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 t
On Sun, 19 May 2002 23:34:24 -0400
"Perrin Harkins" <[EMAIL PROTECTED]> wrote:
: 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)
I am using the Error module in my curr
> So am I being overly paranoid concerning the "leak" potential of
mod_perl
> programming?
No, memory management is very important with mod_perl.
> 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
> i
Not long ago, Gregory Matthews proclaimed...
> So am I being overly paranoid concerning the "leak" potential of mod_perl
> programming?
No... But once you do it "right" it comes natural.
The thing that killed me when I first started doing mod_perl development
was code that pushed items onto li
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 i
> 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
b
At 15:50 15/03/2001 -0300, Jason Leidigh wrote:
>I was able to clean up a number of errors which seemed as
>though they were indeed causing leaks. For example:
>
>$regex = qr'xx?'i;
>
>Causes the following error:
>
>(?i-xsm:xx?) can't `Regexp::DESTROY'
AUTOLOADs will catch DESTROYs, the latter
On Tue, 2 Jan 2001, Per 'stripe' Moeller wrote:
> Hi,
>
> I have created a highly configurable content management system in modperl to
> build websites, which consists of several modules, some preload when apache
> initiates, some when a request initiates and some when needed.
>
> I had the oppor
On Sat Jan 29 13:11:25 2000 + Mike Whitaker wrote:
> [EMAIL PROTECTED] (Doug MacEachern) wrote:
> >there are hints in the SUPPORT doc on how to debug such problems. there
> >was also several "Hanging process" threads in the past weeks with more
> >tips, search in the archives for keywords gd
On Wed, Nov 03, 1999 at 10:40:08PM -0500, David Huggins-Daines wrote:
> I have more or less the same problem as Ben here. mod_perl appears to leak
> memory on SIGHUP proportionately to the number of extra Perl modules loaded
> into the interpreter
I think to some extent individual modules are to
On Thu, Nov 04, 1999 at 12:32:07PM +, Ben Bell wrote:
> Bug 34947 might be a different problem. But if it is, the poster stated
> that statically linked 1.3.3/1.16_02 worked well for him. I'll see if
> I can track down some earlier versions and build them like this.
It's DSO related for sure,
On Sun, Oct 31, 1999 at 11:33:19PM -0800, Doug MacEachern wrote:
> sounds like you have PerlFreshRestart On, try turning it Off. scan the
> archives for more info.
I have tried both ways. Also, the mail archives say that this is a bug that
was fixed in 1.21 (which I am running).
I've done some mo
sounds like you have PerlFreshRestart On, try turning it Off. scan the
archives for more info.
On Fri, 29 Oct 1999, Ben Bell wrote:
> Hi,
>
> I'm using the Debian package of mod_perl (1.21) and apache 1.3.9 and
> I've noticed quite nasty memory leaks on server restart. I've noticed
> unresolve
35 matches
Mail list logo
