thing -- logged the request in an early stage before handling it. But
you can do that with mod_perl.
This does not sound like a memory leak to me. Those are slow and can be
handled with something like Apache::SizeLimit. This sounds like some of
your Perl code is loading too much into memory for
If this is a memory leak, won't the last request to be sent to the mod_perl
worker process be the last straw and not necessarily the culprit? What if
the leak is in some library code that's used in every request?
On Tue, Sep 6, 2016 at 12:43 PM, John Dunlap wrote:
> My fear wit
My fear with logging the complete data input is that it will make the
problem worse for my customers because this problem is only happening on
heavily loaded servers. I can't reproduce it locally.
On Tue, Sep 6, 2016 at 11:26 AM, Perrin Harkins wrote:
> Hi John,
>
> The key is usually finding ou
Hi John,
The key is usually finding out what the request was that caused it. You can
add the pid to your access logging, or write a more complete mod_perl
handler to log the complete data input along with the pid. Then you just go
back and look at what it was after you see which process was killed
The system load reported by the uptime command, on one of my servers,
periodically spikes to 20-30 and then, shortly thereafter, I see this in
dmesg:
[2887460.393402] Out of memory: Kill process 12533 (/usr/sbin/apach) score
25 or sacrifice child
[2887460.394880] Killed process 12533 (/usr/sbin/ap
Fred,
> Andreas: Are you also running PostgreSQL as Jonathan and I are?
Yes, I am running the current 8.1.4 with current DBI 1.52 and DBD::Pg 1.49.
> Andreas & Jonathan: Are either of you running reiserfs? (Perhaps it is
> the filesystem causing this.)
The machine which crashes every 14 days be
IIRC, didn't we track this to Postgresql ? If so, we should
relocate to the postgresql lists.
Not officially/definitively, though i've already posted it to the
pgsql lists. ( and ruled out bsd as being the cause thanks to some
friends with NYC BSD UG )
Fred Tyler wrote:
> Linux 2.6.12.6
> Apache 1.3.33
> Postgresql 7.4.9
> mod_perl 1.29
> 350-400 viritual hosted domains, all running a mod_perl/postgres backed
> CMS.
IIRC, didn't we track this to Postgresql ? If so, we should relocate to the
postgresql lists.
--
--
st for basic processes, and
eventually crashing.
It looks a lot like a kernel memory leak, and for the past few months
that is what I've assumed it was. I don't know how else to explain the
fact that no processes are running but the kernel still sees all the
RAM taken. However, the fact t
On Wed, 6 Sep 2006 19:09:15 -0400
Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
> On Sep 6, 2006, at 6:41 PM, Frank Wiles wrote:
>
> >Is that 500MB that "vanished" in used, buffers, or cached? Just
> >because it isn't listed in "free" doesn't mean it isn't "free"
> > from a "Available memo
On Sep 6, 2006, at 6:41 PM, Frank Wiles wrote:
Is that 500MB that "vanished" in used, buffers, or cached? Just
because it isn't listed in "free" doesn't mean it isn't "free" from
a "Available memory I can use" standpoint. For example, your
system
will reclaim memory from cached
On Wed, 6 Sep 2006 18:26:46 -0400
Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
>
> On Sep 6, 2006, at 6:01 PM, Frank Wiles wrote:
>
> >It didn't disappear, and it isn't "shared" like the type of
> > sharing we talk about with mod_perl/Apache. It's not CoW sharing.
> I know.
>
> >The shar
On Sep 6, 2006, at 6:01 PM, Frank Wiles wrote:
It didn't disappear, and it isn't "shared" like the type of sharing
we talk about with mod_perl/Apache. It's not CoW sharing.
I know.
The shared memory you're talking about here is held by the
postmaster
daemon and is used to store
On Wed, 6 Sep 2006 17:36:50 -0400
Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
> From what I can tell, this is happening:
> bootup: ( pg ) 861 Free
> apache start: ( apache , pg , 3x pg clients ) 785 Free
> apache stop:( pg, 3x pg clients ) 840 Free
> apache start:
On Aug 18, 2006, at 6:24 AM, Andreas Rieke wrote:
Hi,
after booting a redhat enterprise linux 3 machine with apache 2.0.58,
perl 5.8.8 and mod_perl 2.0.2,
it runs well using about 300 M of 1 G physical RAM.
However, the remaining RAM decreases day by day, and after 2 or 3
weeks, the machine cra
On Fri, 2006-08-18 at 19:35 +0200, Andreas Rieke wrote:
> as the memory is even gone after apache with mod_perl has been stopped,
> I do not think that this really helps. I do know that the kernel should
> recover all the memory when processes stop even if these did not free
> the memory, thus it s
Perrin Harkins wrote:
>On Fri, 2006-08-18 at 12:24 +0200, Andreas Rieke wrote:
>
>
>>it runs well using about 300 M of 1 G physical RAM.
>>However, the remaining RAM decreases day by day, and after 2 or 3
>>weeks, the machine crashes because swapping takes too much time.
>>However, all processes
Clinton Gormley wrote:
>On Fri, 2006-08-18 at 12:24 +0200, Andreas Rieke wrote:
>
>
>>Hi,
>>
>>
>>
>
>
>
>>The strange thing is that all the memory is gone even after stopping all
>>apache processes.
>>The only thing which helps is to reboot the machine.
>>
>>
>>
>
>Hi Andreas
>
>Not m
Are you using the RH / SuSE versions of mp/apache and postgres ? Or
did you compile your own?
I my experience, on those systems its best to compile your own. The
packages are often way out of date and have issues that have been
solved.
I've found that running Postgres and MP on the same
Perrin Harkins wrote:
On Fri, 2006-08-18 at 12:24 +0200, Andreas Rieke wrote:
it runs well using about 300 M of 1 G physical RAM.
However, the remaining RAM decreases day by day, and after 2 or 3
weeks, the machine crashes because swapping takes too much time.
However, all processes together tak
On Fri, 2006-08-18 at 12:24 +0200, Andreas Rieke wrote:
> it runs well using about 300 M of 1 G physical RAM.
> However, the remaining RAM decreases day by day, and after 2 or 3
> weeks, the machine crashes because swapping takes too much time.
> However, all processes together take about 250 MByte
On Fri, 2006-08-18 at 12:24 +0200, Andreas Rieke wrote:
> Hi,
>
> The strange thing is that all the memory is gone even after stopping all
> apache processes.
> The only thing which helps is to reboot the machine.
>
Hi Andreas
Not my field of expertise, but this sounds like a kernel problem, o
Hi,
after booting a redhat enterprise linux 3 machine with apache 2.0.58,
perl 5.8.8 and mod_perl 2.0.2,
it runs well using about 300 M of 1 G physical RAM.
However, the remaining RAM decreases day by day, and after 2 or 3
weeks, the machine crashes because swapping takes too much time.
However, a
My system have seem memory leak problem. The MEM_USR
raise .
But how to debug?? Is the Apache::Leak for mod_perl v1.x
module?
PS:apache Apache/2.0.54 + MOD_PERL 2
no database
<>
Compress::Zlib;Crypt::RC5;Digest::MD4
'md4_hex';Data::Dumper;Encode::TW;Fcntl qw(:DEFAU
Max Kanat-Alexander wrote:
But one way or another, this does seem like a bug. That DESTROY handler
ought to get called.
By saying go out of scope, or holding a reference, he is implying that the
reference count is not = 0
ever. When a "object"'s ref count reaches 0, DESTROY is called.
On Fri, 2006-06-30 at 18:49 -0400, Jonathan Vanasco wrote:
> I think its more likely that the bug is in the way Bugzilla uses TT
> -- a some reference to the template object is getting stored
> persistently ( i think everyone has made a similar mistake ). I've
> never had a problem with a pn
On Jun 30, 2006, at 6:20 PM, Max Kanat-Alexander wrote:
On Fri, 2006-06-30 at 00:37 -0400, Perrin Harkins wrote:
HOWEVER: If I "delete $r->pnotes->{template}" before the script
ends,
there's no memory leak.
It sounds like a problem with the DESTROY method in
Templ
On Fri, 2006-06-30 at 00:37 -0400, Perrin Harkins wrote:
> > HOWEVER: If I "delete $r->pnotes->{template}" before the script ends,
> > there's no memory leak.
>
> It sounds like a problem with the DESTROY method in Template::Provider.
> Can you ad
plate}" before the script ends,
there's no memory leak.
It sounds like a problem with the DESTROY method in Template::Provider.
Can you add some logging to that method to see if it gets called?
- Perrin
Hi. I'm working on making Bugzilla support mod_perl.
I have a very strange memory leak.
Bugzilla uses the Template Toolkit (TT2).
We're using MP2. In particular, 1.999022 (aka 2.0.0-RC5). I've also
tested the below on 2.0.1, with the same results.
Title: Memory Leak when using PerlAccessHandler (WIN32/Apache2/PERL5.8.3).
I'm experiencing a memory leak when using the PerlAccessHandler handler. The leak is very slow but certainly exists. I've dumbed down the handler to its simplest form:
package Apache2::MYHANDLER;
use st
> > rev 1.61
>
> "Switch to perlmalloc by
> default, unless threaded perl is built, to improve performance."
>
> > rev 1.49
>
> "WITH_PERL_MALLOC - to compile with perl's own malloc, as opposed to
>the freebsd system malloc. Some might find this useful, since perl's
>malloc is marginally
Philip M. Gollucci wrote:
> Philippe M. Chiasson wrote:
>> Philip M. Gollucci wrote:
>>> Philippe M. Chiasson wrote:
>>>
>> Poking [EMAIL PROTECTED] about this issue could possibly help,
>> especially if
>> the reason this was done can be shown not to apply anymore.
>>
> http://www.freebsd.org/c
Philippe M. Chiasson wrote:
Philip M. Gollucci wrote:
Philippe M. Chiasson wrote:
Poking [EMAIL PROTECTED] about this issue could possibly help, especially if
the reason this was done can be shown not to apply anymore.
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/perl5.8/Makefi
Philip M. Gollucci wrote:
> Philippe M. Chiasson wrote:
>
>> I've encouontered this problem before on FreeBSD and have had some
>> success
>> working around it. One of the main problems seems to be with FreeBSD's
>> Perl
>> build picking Perl's malloc instead of the native FreeBSD malloc().
>> You
Philippe M. Chiasson wrote:
I've encouontered this problem before on FreeBSD and have had some success
working around it. One of the main problems seems to be with FreeBSD's Perl
build picking Perl's malloc instead of the native FreeBSD malloc(). You can see
how your perl is configured like this
snacktime wrote:
> Before I spend a whole lot of time on this I'm curious if someone else
> has run across this. This is mod perl 1.29.
>
> We upgraded perl on one of our freebsd 5.4 servers from 5.6.1 to
> 5.8.7. This included reinstalling around 50 perl modules (some to new
> versions) from th
snacktime wrote:
Before I spend a whole lot of time on this I'm curious if someone else
has run across this. This is mod perl 1.29.
We upgraded perl on one of our freebsd 5.4 servers from 5.6.1 to
5.8.7. This included reinstalling around 50 perl modules (some to new
versions) from the freebsd
Before I spend a whole lot of time on this I'm curious if someone else
has run across this. This is mod perl 1.29.
We upgraded perl on one of our freebsd 5.4 servers from 5.6.1 to
5.8.7. This included reinstalling around 50 perl modules (some to new
versions) from the freebsd ports. Ever since
Jean-François Nadeau wrote:
Thanks for the quick reply.
I cleaned up my installation and reinstalled.
See attached bug report and BuildConfig.pm.
Configured with:
perl Makefile.PL MP_INST_APACHE2=1 MP_AP_PREFIX=/usr/local/apache-2.0.52/
make && make install
The leak persist after reinstall.
Co
Configured with:
perl Makefile.PL MP_INST_APACHE2=1 MP_AP_PREFIX=/usr/local/apache-2.0.52/
make && make install
OK. Why do you use MP_AP_PREFIX and not MP_APXS? The docs suggest to use
the latter:
http://perl.apache.org/docs/2.0/user/intro/start_fast.html#Installation
http://perl.apache.org/docs
a sample script at the moment...
Regards,
Jean
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]
Sent: 21 décembre 2004 11:26
To: Jean-François Nadeau
Cc: [EMAIL PROTECTED]
Subject: Re: PerlRun Memory leak upgrading from 1.99_14 to 2.0.0-RC1
Jean-François Nadeau wrote:
> Hi a
Jean-François Nadeau wrote:
Hi all,
I was using mod_perl-1.99_14 under Apache 2.0.49,
I upgraded to mod_perl-2.0.0-RC1 under Apache 2.0.52.
Im using RedHat 8.0 / perl 5.8.0 / CGI.pm 3.05
Apache configuration :
SetHandler perl-script
PerlResponseHandler ModPerl::PerlRun
PerlOptions +Par
:15To: [EMAIL PROTECTED]Subject: PerlRun Memory
leak upgrading from 1.99_14 to 2.0.0-RC1
Hi
all,
I was using
mod_perl-1.99_14 under Apache 2.0.49,
I upgraded to
mod_perl-2.0.0-RC1 under Apache 2.0.52.
Im using RedHat 8.0
/ perl 5.8.0 / CGI.pm 3.05
Apache configuration
:
SetHandler
Hi
all,
I was using
mod_perl-1.99_14 under Apache 2.0.49,
I upgraded to
mod_perl-2.0.0-RC1 under Apache 2.0.52.
Im using RedHat 8.0
/ perl 5.8.0 / CGI.pm 3.05
Apache configuration
:
SetHandler
perl-script PerlResponseHandler ModPerl::PerlRun PerlOptions
+ParseHeaders +GlobalReq
Ged Haywood wrote:
Hi there,
On Mon, 9 Feb 2004, Richard F. Rebel wrote:
After upgrading to perl 5.8.1 from 5.8.0 during a distribution upgrade,
I noticed a steady memory leak that eventually leads to the server
failing.
:(
My question is, for a persistent mp2 app, is there a potential way
Hello again,
On Mon, 9 Feb 2004, Richard F. Rebel wrote:
> upgrading/downgrading distro provided base perl installations is
> often more of a nightmare than it's worth.
It can sometimes cause a little frustration, so I prefer to avoid the
versions provided by the distributions in the first place
2004-02-09 at 13:11, Ged Haywood wrote:
> Hi there,
>
> On Mon, 9 Feb 2004, Richard F. Rebel wrote:
>
> > After upgrading to perl 5.8.1 from 5.8.0 during a distribution upgrade,
> > I noticed a steady memory leak that eventually leads to the server
> > failing.
>
&
Hi there,
On Mon, 9 Feb 2004, Richard F. Rebel wrote:
> After upgrading to perl 5.8.1 from 5.8.0 during a distribution upgrade,
> I noticed a steady memory leak that eventually leads to the server
> failing.
:(
> My question is, for a persistent mp2 app, is there a pote
ated pages per
day using the worker mpm.
After upgrading to perl 5.8.1 from 5.8.0 during a distribution upgrade,
I noticed a steady memory leak that eventually leads to the server
failing.
Stas found a similar problem and isolated it to the s/// operator. I
have followed the debugging method that
On Thu, 2003-12-11 at 22:00, Stas Bekman wrote:
> Raul Dias wrote:
> > I did mean to sound as a rant (if I did). I know that's not easy to
> > keep with the documentation.
>
> what can you do with your subconscious which seems to tell the truth of what
> you've really meant ;)
>
>:)
> Doc pat
Raul Dias wrote:
perl-5.8.3-ithread -MApache2 -MModPerl::MethodLookup -e print_object
Apache::RequestRec | wc -l
149
Great. This is a good start point for me.
In that case please see:
http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#top
I did mean to sound as a rant (if I did).
On Thu, 2003-12-11 at 20:43, Stas Bekman wrote:
> Raul Dias wrote:
> > On Thu, 2003-12-11 at 16:30, Stas Bekman wrote:
> >
> >>Raul Dias wrote:
> >>
> >>>On Wed, 2003-12-10 at 20:42, Stas Bekman wrote:
[...]
> > It would really help to have some section about all the methods
> > available to $fil
Raul Dias wrote:
On Thu, 2003-12-11 at 16:30, Stas Bekman wrote:
Raul Dias wrote:
On Wed, 2003-12-10 at 20:42, Stas Bekman wrote:
Lastly, why does the memory continue to be consumer after the client has
terminated the connection?
Because the server doesn't realize that the connection was abort
On Thu, 2003-12-11 at 16:30, Stas Bekman wrote:
> Raul Dias wrote:
> > On Wed, 2003-12-10 at 20:42, Stas Bekman wrote:
> >
> >
> >>>Lastly, why does the memory continue to be consumer after the client has
> >>>terminated the connection?
> >>
> >>Because the server doesn't realize that the connect
Raul Dias wrote:
On Wed, 2003-12-10 at 20:42, Stas Bekman wrote:
Lastly, why does the memory continue to be consumer after the client has
terminated the connection?
Because the server doesn't realize that the connection was aborted. You can
check that with $c->aborted. It could also be a bug in
Hi
Got rather a shock this morning when I discovered twenty odd emails in
my Inbox!! I can see why open source development moves so fast ;)
;)
The version in CVS looks good. It consumes very little memory now,
starts off at 0.6%. I think there is still a small leak, it creaps up
very slowly at ab
On Wed, 2003-12-10 at 20:42, Stas Bekman wrote:
> > Lastly, why does the memory continue to be consumer after the client has
> > terminated the connection?
>
> Because the server doesn't realize that the connection was aborted. You can
> check that with $c->aborted. It could also be a bug in Apa
: +44 117 31 29664
> -Original Message-
> From: Stas Bekman [mailto:[EMAIL PROTECTED]
> Sent: 11 December 2003 07:44
> Cc: Pringle, Chris (HP-PSG); [EMAIL PROTECTED]
> Subject: Re: [mp2] Memory Leak
>
>
> Stas Bekman wrote:
> > Pringle, Chris (HP-PSG) wrot
Stas Bekman wrote:
Pringle, Chris (HP-PSG) wrote:
Stas,
I tried the latest version this morning, and it doesn't appear to have
made a great deal of difference. I'm not sure whether it consumes memory
as fast, however, as you said, there are leaks elsewhere. The following
code reproduces it.
Chri
Pringle, Chris (HP-PSG) wrote:
Stas,
I tried the latest version this morning, and it doesn't appear to have
made a great deal of difference. I'm not sure whether it consumes memory
as fast, however, as you said, there are leaks elsewhere. The following
code reproduces it.
[...]
I tested it with t
Pringle, Chris (HP-PSG) wrote:
Stas,
I tried the latest version this morning, and it doesn't appear to have
made a great deal of difference. I'm not sure whether it consumes memory
as fast, however, as you said, there are leaks elsewhere. The following
code reproduces it.
Thanks Chris, I'll take
PSG
Hewlett-Packard, Bristol
Tel: +44 117 31 29664
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Stas Bekman
> Sent: 10 December 2003 02:04
> Cc: Pringle, Chris (HP-PSG); [EMAIL PROTECTED]
> Subject: Re: [mp2] Memory Leak
Pringle, Chris (HP-PSG) wrote:
You will find a few comments regarding your code below:
sub handler
{
# Get the filter object
my($f,$bb) = @_;
my $c = $f->c;
You probably don't need $c, you seem to be in the request filter...
# Declare a buffer
my($buffer) = "";
my($s
Stas Bekman wrote:
Pringle, Chris (HP-PSG) wrote:
Hi,
Apologies for it not being in the correct format.
I wasn't after format but the information ;)
Below is a small section of code that I'm having problems with.
Thanks for the code sample. It allowed me to single out the guilty
element, w
Pringle, Chris (HP-PSG) wrote:
Hi,
Apologies for it not being in the correct format.
I wasn't after format but the information ;)
Below is a small section of code that I'm having problems with.
Thanks for the code sample. It allowed me to single out the guilty element,
which was $f->ctx (I thin
urn Apache::OK;
} # handler
1;
---
Regards,
Chris Pringle
UK PSG
Hewlett-Packard, Bristol
Tel: +44 117 31 29664
> -Original Message-
> From: Stas Bekman [mailto:[EMAIL PROTECTED]
> Sent: 08 December 2003 19:04
> To: Pringle, Chris (HP-PSG)
> Cc: [EMAIL PROTECTED]
> Subje
Pringle, Chris (HP-PSG) wrote:
Hi All,
Anyone experience problems with filters and large files?
I tried to download a 650MB ISO image through my proxy with a filter
enabled and it caused the box to run out of memory, thrash and
eventually panic.
Its a stream based output filter that sits in a loo
Hi All,
Anyone experience problems with filters and large files?
I tried to download a 650MB ISO image through my proxy with a filter
enabled and it caused the box to run out of memory, thrash and
eventually panic.
Its a stream based output filter that sits in a loop doing
$f->read(...). Even wh
Stefan Thuering wrote:
Platform: NT4 SP6, Apache 1.3.27/28, mod_perl 1.28, perl 5.6.1
Scenario: When running any script (print hello...) multiple times memory
usage of apache slowly grows (maybe 400byte/request)
Apache Setting:
ScriptAlias /perl/ "E:/Apache/cgi-bin/"
SetHandler perl-script
Per
Platform: NT4 SP6, Apache 1.3.27/28, mod_perl 1.28, perl 5.6.1
Scenario: When running any script (print hello...) multiple times memory
usage of apache slowly grows (maybe 400byte/request)
Apache Setting:
ScriptAlias /perl/ "E:/Apache/cgi-bin/"
SetHandler perl-script
PerlHandler Apache::Regist
71 matches
Mail list logo
