:
Subject: Identifying memory leaks
11/26/2002 02:28
PM
A Linux machine running Apache/2.0.35 (Unix) mod_perl/1.99_05-dev
Perl/v5.6.1 mysql 4.0.1 uses increasing used memory (according
/usr/bin/free), eventually resuting in all memory being consumed. Memory
usage drops somewhat after a reboot of apache and mysql, but not completely.
If a reference
Charles wrote:
A Linux machine running Apache/2.0.35 (Unix) mod_perl/1.99_05-dev
Perl/v5.6.1 mysql 4.0.1 uses increasing used memory (according
/usr/bin/free), eventually resuting in all memory being consumed. Memory
usage drops somewhat after a reboot of apache and mysql, but not completely.
Hi,
I'm using ActiveState Perl v5.6.1 MSWin32-x86-multi-thread,
Apache 1.3.26 and mod_perl 1.27 ( as DSO ) on Windows 2000
with 256MB of RAM. I configurel location in a simple way,
showed below:
-- a piece from httpd.conf
Location /mod_perl
Options +ExecCGI
AddHandler
Andrey Prokopenko wrote:
After a fresh restart, I started Apache/mod_perl. Then i issued a
little stress test using simple perl script with LWP::Simple.
I ran a performance test on /mod_perl/index.pl page for 10 minutes. The
source code of that page is given below :
-
Hello Perrin,
Tuesday, June 25, 2002, 6:40:01 PM, you wrote:
PH Andrey Prokopenko wrote:
After a fresh restart, I started Apache/mod_perl. Then i issued a
little stress test using simple perl script with LWP::Simple.
I ran a performance test on /mod_perl/index.pl page for 10 minutes. The
PROTECTED]
Subject: Re[2]: mod_perl memory leaks on Windows
Hello Perrin,
Tuesday, June 25, 2002, 6:40:01 PM, you wrote:
PH Andrey Prokopenko wrote:
After a fresh restart, I started Apache/mod_perl. Then i issued a
little stress test using simple perl script with LWP::Simple.
I ran
Andrey Prokopenko wrote:
I tried a plain Perl cgi script, with no module used, and still the
same. ;((
Do you mean that this leak cannot be fixed from Apache/mod_perl side ?
I can't say for sure since I don't use mod_perl on Win32, but most of
the process growth problems reported when using
DM == Doug MacEachern [EMAIL PROTECTED] writes:
DM what version of perl? what modperl Makefile.PL options?
DM if you're using modperl as a dso, you'll need at least perl 5.6.1 and
DM modperl-1.26 to prevent this leakage on restarts.
Even with these versions, I get massive leakage on restart
At 6:56 PM -0700 5/21/02, Doug MacEachern wrote:
On Tue, 21 May 2002, Dan Wilga wrote:
I am using Perl 5.6.1, modperl 1.25, and yes it's a DSO. It's compiled with:
with 1.25, you can also set the PERL_DESTRUCT_LEVEL environment variable
to 2, either before starting the server:
export
On Wed, 22 May 2002, Dan Wilga wrote:
Interesting. When I do that, I get the same problem I did when I
tried to run with 1.25_01 and 1.26: Apache core dumps. I think I'll
have to try compiling it again with the latest version of mod_perl,
and perhaps not as a DSO.
possible that your are
At 8:41 AM -0700 5/22/02, Doug MacEachern wrote:
On Wed, 22 May 2002, Dan Wilga wrote:
Interesting. When I do that, I get the same problem I did when I
tried to run with 1.25_01 and 1.26: Apache core dumps. I think I'll
have to try compiling it again with the latest version of mod_perl,
On Wed, 22 May 2002, Dan Wilga wrote:
Oh ho! That's it. Now when I gracefully restart, the memory loss is
only about 29 Kb -- a very reasonable number.
much better. with the modperl test suite, i only see a wee bit of leakage
on the first restart, then no leakage on restarts after that.
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
All this talk about memory leakage has got me to wondering more about
a problem I've noticed with mod_perl ever since I started using it:
the more times you gracefully restart, the more memory you lose.
This doesn't seem to be a result of the type of leakage that's being
discussed in the
what version of perl? what modperl Makefile.PL options?
if you're using modperl as a dso, you'll need at least perl 5.6.1 and
modperl-1.26 to prevent this leakage on restarts.
At 10:34 AM -0700 5/21/02, Doug MacEachern wrote:
what version of perl? what modperl Makefile.PL options?
if you're using modperl as a dso, you'll need at least perl 5.6.1 and
modperl-1.26 to prevent this leakage on restarts.
I am using Perl 5.6.1, modperl 1.25, and yes it's a DSO. It's
At 02:15 PM 5/21/02 -0400, Dan Wilga wrote:
I am using Perl 5.6.1, modperl 1.25, and yes it's a DSO. It's compiled with:
USE_APACI=1 SSL_BASE=/usr/local/ssl DO_HTTPD=1
So I guess the solution is to go to 1.26 or newer; I'll try that later in
the week.
Or to just compile mod_perl
On Tue, 21 May 2002, Dan Wilga wrote:
I am using Perl 5.6.1, modperl 1.25, and yes it's a DSO. It's compiled with:
with 1.25, you can also set the PERL_DESTRUCT_LEVEL environment variable
to 2, either before starting the server:
export PERL_DESTRUCT_LEVEL=2
apachectl start
or using
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
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
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
.
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
, 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
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
are downloading big
files. They might have to restart from the beginning if they didn't cache
the partial download somewhere.
Hmm, if you are serving big files off of mod_perl, memory leaks are the
least of your problems :) That doesn't apply to Apache::MP3 of course, for
which it's normal
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
the connection was closed.
This might cause a problem for you if your users are downloading big
files. They might have to restart from the beginning if they didn't cache
the partial download somewhere.
Hmm, if you are serving big files off of mod_perl, memory leaks are the
least of your problems
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
because the connection was closed.
This might cause a problem for you if your users are downloading big
files. They might have to restart from the beginning if they didn't
cache
the partial download somewhere.
Hmm, if you are serving big files off of mod_perl, memory leaks are
the least
have to restart from the beginning if they didn't cache
the partial download somewhere.
Hmm, if you are serving big files off of mod_perl, memory leaks are the
least of your problems :) That doesn't apply to Apache::MP3 of course,
for which it's normal, but in no case should your mod_perl server
cause a problem for you if your users are downloading big
files. They might have to restart from the beginning if they didn't
cache
the partial download somewhere.
Hmm, if you are serving big files off of mod_perl, memory leaks are the
least of your problems :)
Well, you can serve big
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
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
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
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 the the mod_perl/Apache web site (http://perl.apache.org/faq/#Why_is_httpd_using_so_much_memor)
there is a section about memory usage and a
subroutine is given which can help test for memory leaks which perl "does no
overtly report"
Joel Wagner reports that calling an
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
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 to test the system with 2000 lan connected users to
else experienced this kind of problem?
Lots of people. Memory leaks are very easy to introduce, and very hard to
find. The most likely causes are closures, circular references, and bad
modules. Not necessarily in that order :-)
Another problem I encountered... when doing HTTP upload's, apache
Hi,
I have an Apache 1.3.12 server running on a Sun e450 with Solaris 7, Perl
5.6.0, and mod_perl 1.24. When I was testing the server everything seemed to
be ok, but once I moved the real content (including a bunch of perl CGI
scripts) onto it, I noticed that memory slowly gets eaten up. If I do
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,
[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, .gdbinit, curinfo
if you can get more insight from those tips,
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
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 bug reports on the Debian pages about this. Is it a known
issue with this version?
The leak is ca. 2MB each restart (or graceful) with my
56 matches
Mail list logo
