arles"
eak.com> cc:
Subject: Identifying
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.
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 referenc
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 usin
1 AM
> To: [EMAIL 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
> >> l
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
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 :
> -
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
Options +ExecCGI
AddHandler perl-script .pl
PerlHandle
> "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 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.
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_p
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
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 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 PerlSet
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 st
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 com
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.
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 other
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
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 f
cause 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
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
uns 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 have to restart from the beginning if they didn't
>> cache
>> the partial download s
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
ext track -- presumably 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 a
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
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 :) That doesn't apply
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
&
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 w
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
> > > >
> > > >
> &
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
gt; 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.:
>
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
uestions 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 s
> 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 ne
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
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
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
quests, otherwise they would consume too much memory.
>
> Have anybody 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 ord
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 do
"Rob Egan" <[EMAIL PROTECTED]> writes:
> 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,
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 gd
[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 tip
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,
Hi,
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 (though without any PerlRequire directives or
PerlHandlers or sections it still leaks about 64k of memory on each
SIGHU
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
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 gr
61 matches
Mail list logo
