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
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 current
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 the Error
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 Exception: $e;
:
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 with {
:
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 before
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{__DIE__} handler installed
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
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 about
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,
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?
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
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 have a
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
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
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 users
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
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
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'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.
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
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 might
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,
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
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 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 lists
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
issues
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 being
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 opportunity
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 gdb,
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
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
unresolved
32 matches
Mail list logo
