Hann, Brian wrote:
I'm having a problem with a fairly simple handler eating up resources
and I'm wondering if there's any easy way to track it down.
The handler fetches data from an Oracle database and displays it
using Template-Toolkit. Nothing fancy, just some display logic, etc.
The
I'm having a problem with a fairly simple handler eating up resources and I'm
wondering if there's any easy way to track it down.
The handler fetches data from an Oracle database and displays it using
Template-Toolkit. Nothing fancy, just some display logic, etc.
The thing is, when I try to
Brian,
Are you trying to read the entire 8000 records into a
single array/hash? You might try splitting the record
set into pieces and reuse that array/hash.
-- Joe Palladino
Hann, Brian wrote:
I'm having a problem with a fairly simple handler
eating up resources and I'm wondering if
KGM == Keith G Murphy [EMAIL PROTECTED] writes:
KGM When using a modular mod_perl, I get a huge leak if I preload the 'Pg'
KGM driver in my startup perl script thus:
Hmmm. Interesting theory. I shall have to investigate it. I also
see a multi-megabyte memory leak in my app when DBD::Pg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
OK, it gets weirder. The following script produces the leak. If I
comment out the install_driver line, I get a big old segfault! Same
if I comment out the Apache::DBI line in addition. This works with
plain apache, or apache-ssl.
Juha-Mikko Ahonen wrote:
I looked into it with the following setup:
apache 1.3.26-0woody1
libapache-mod-perl 1.27-2
postgresql 7.2.1-2woody2
There was a Test.pm module handling all requests for /. It opened a
connection to the database and fetched a couple of rows.
With
Since memory leaks seem to be the topic du jour, I wondered if anyone
else had seen this one:
When using a modular mod_perl, I get a huge leak if I preload the 'Pg'
driver in my startup perl script thus:
#!/usr/bin/perl
use strict;
use Apache::Status ();
use Apache::DBI ();
Using Debian's static-mod_perled apache-perl eliminates the problem.
Do you mean you are using the 'so' version that comes with Debian? You
should be using the static build of apache/mod_perl
Stathy G. Touloumis wrote:
Using Debian's static-mod_perled apache-perl eliminates the problem.
Do you mean you are using the 'so' version that comes with Debian?
Yes, in the case that failed. The package is called 'libapache-mod-perl'.
You
should be using the static build of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 16 October 2002 20:25, Keith G. Murphy wrote:
By should, do you mean that the problems with the loadable module
overall are so well-known that no one in his right mind should ever
use it?
Yes. The problems with DSO mod_perl are well
Hi there,
On Wed, 16 Oct 2002, Keith G. Murphy wrote:
do you mean that the problems with the loadable module overall are
so well-known that no one in his right mind should ever use it?
It's not as bad as that. Significant improvements have been made in
the reliability of mod_perl as DSO and
with it.
If at first you don't succeed, try again. Then give up.
Actually, that is what I have done already, several months ago. Seeing
several reports of memory leak problems in the list made me think:
Hmmm, wonder if someone else has seen this?
Juha-Mikko Ahonen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 16 October 2002 20:25, Keith G. Murphy wrote:
By should, do you mean that the problems with the loadable module
overall are so well-known that no one in his right mind should ever
use it?
Yes. The
[mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 2:02 PM
To: mod_perl Mailing List
Subject: Re: Memory leak on reload when the 'Pg' driver is preloaded
Ged Haywood wrote:
Hi there,
On Wed, 16 Oct 2002, Keith G. Murphy wrote:
do you mean that the problems
Hi there,
On Wed, 16 Oct 2002, Keith G. Murphy wrote:
Significant improvements have been made in
the reliability of mod_perl as DSO and nowadays there is much less
discussion about it on this list.
Are you sure it's not because 'most everyone has silently given up on it?
Yes, I'm
Ged Haywood wrote:
Hi there,
On Wed, 16 Oct 2002, Keith G. Murphy wrote:
Significant improvements have been made in
the reliability of mod_perl as DSO and nowadays there is much less
discussion about it on this list.
Are you sure it's not because 'most everyone has silently given up on
On Wed, Oct 16, 2002 at 02:01:33PM -0500, Keith G. Murphy wrote:
Ged Haywood wrote:
Hi there,
On Wed, 16 Oct 2002, Keith G. Murphy wrote:
do you mean that the problems with the loadable module overall are
so well-known that no one in his right mind should ever use it?
It's not as
Daniel Jacobowitz wrote:
On Wed, Oct 16, 2002 at 02:01:33PM -0500, Keith G. Murphy wrote:
My own bug report is now 47 days old, without apparent followup.
Hmmm, I probably should not have posted that. Sounds like a major whine.
That's because I'm having an attack of real life. I haven't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 16 October 2002 22:52, Keith G. Murphy wrote:
It's not like it was an obvious problem: I only got the DSO to leak
when loading the Pg driver. That's pretty obscure.
Have you tried to connect() without loading the Pg driver first?
[debian-isp readers, to recap, I'm trying to confirm a
memory-leak/segfault problem with Debian stable plus apache(-ssl) plus
libapache-mod-perl. The memory leak happens upon
/etc/init.d/apache(-ssl) reload. You can see my startup script and my
other comments below.]
Juha-Mikko Ahonen
I'm dealing with a large code base here and I'm hoping to find out what is
being loaded into memory to make an Apache child jump from 25mb to 145mb
(interestingly it seems to only affect one every now and then rather than
the whole pool) in about 10 seconds. Is there a way to have Apache dump
Jack Cushman wrote:
I am having a problem with very large file uploads (eg 100 MB). While the
files load, the apache process stays at about 12000 K (the ps VSZ size).
When the file finishes uploading, the thread suddenly jumps to over
20.
My guess is that something is loading the whole
DM == Doug MacEachern [EMAIL PROTECTED] writes:
DM 1.21_01 had two dso fixes, one to close all .so's opened by DynaLoader and
DM one to call perl_shutdown(), both of which were large leaks. with
DM 1.25_01-dev and Perl 5.6.1 i see a 4k growth on the first kill -USR1 and
DM no change after
I know that this is an ongoing problem, but I seem to remember that
someone somewhere had a patch that reduced the size of the memory leak on
restarts to a manageable size. Has this patch been applied to the CVS
version? If not, can some kind soul tell me where to find it? I've
looked around
On Thu, 14 Jun 2001, Paul G. Weiss wrote:
I know that this is an ongoing problem, but I seem to remember that
someone somewhere had a patch that reduced the size of the memory leak on
restarts to a manageable size. Has this patch been applied to the CVS
version? If not, can some kind soul
script offers database search facilities on the web. If a search is
performed which results in many (namely 400) rows being returned, then
the httpd child that serves the request grows by 2 MB. Have a child
serve that request ten times, and its size will grow from an initial 8
MB to 28
In case anyone is interested: the memory leak I described a week ago
turns out to be a problem of the combination of HTML::Template with
Perl 5.005_03 (probably a bug in Perl 5.005_03 memory management
triggered by HTML::Template). I upgraded to Perl 5.6.1 and now not a
single byte leaks.
My
Hi all. I have a huge memory leak with mod_perl.
I'm using a RedHat 6.2 Linux 2.2.14 system with Perl 5.00503, Apache
1.3.14, and mod_perl 1.23. Both Apache and mod_perl come from RedHat's
packages, and mod_perl runs as DSO.
My script uses CGI, DBI, Apache::DBI, and HTML::Template. No errors
Hi there,
On Mon, 28 May 2001, Antonios Christofides wrote:
script offers database search facilities on the web. If a search is
performed which results in many (namely 400) rows being returned, then
the httpd child that serves the request grows by 2 MB. Have a child
serve that request ten
apache-thread in opposite of it in the manual clean-up?
Matthias
-Ursprungliche Nachricht-
Von: Ged Haywood [mailto:[EMAIL PROTECTED]]
Gesendet: Montag, 28. Mai 2001 20:08
An: Antonios Christofides
Cc: [EMAIL PROTECTED]
Betreff: Re: Memory leak
Hi there,
On Mon, 28 May 2001, Antonios
On Mon, 28 May 2001, Matthias Hanns wrote:
Hi,
I had the same prob and lowering maxrequestsperchild helped.
Are there possibilities to clean up the used mem on end of the
mod_perl-script manually? Or have I always set maxrequestsperchild to lower
values? If it?s possible to do it by
I have been testing and troubleshooting this for days, and I can find no
other answer to my problem except that DBD::mysql has a memory leak.
I have narrowed it down to this small script running through
Apache::Registry:
use DBI;
use
Hi Mark.
On Thu, 1 Feb 2001, Mark Blythe wrote:
I have been testing and troubleshooting this for days, and I can find no
other answer to my problem except that DBD::mysql has a memory leak.
I have narrowed it down to this small script running through
Apache::Registry
On Fri, 8 Dec 2000, Perrin Harkins wrote:
Unfortunately, GTop is kind of a pain to compile. It seems to depend on
some Gnome stuff. We use Apache::SizeLimit for this reason, and it works
well.
there's a configure --disable-gnome switch for libgtop. can still be a
pain though.
Hi,
I'm experiencing a memory leak with Apache 1.3.14 with mod_perl 1.23 and
perl5.6.0 on Windows NT4.0 and Windows2000.
I've been running some test with a very simple ModPerl handler which just
outputs an HTML page with hello world in it. Also, I made sure to undef all
variables that I use
I've had memory leak issues on Linux [so I don't know how appropriate this advise is
for Windows], and the fix that worked the best for others myself was to actually
kill the apache server restart it. The process takes seconds, and can be automated
scheduled for off-hours. If you search
Son Chang wrote:
Hi,
I'm experiencing a memory leak with Apache 1.3.14 with mod_perl 1.23 and
perl5.6.0 on Windows NT4.0 and Windows2000.
I've been running some test with a very simple ModPerl handler which just
outputs an HTML page with hello world in it. Also, I made sure to undef
all
),
but the right part memory (one more 1M) can be used nowhere except the
same line of code.
This is strange. I understand that it can be an optimization trick,
but when you frequently operate with megabytes, this becomes a
pleasant feature which looks and behaves like a memory leak
memory (one more 1M) can be used nowhere except the
same line of code.
This is strange. I understand that it can be an optimization trick,
but when you frequently operate with megabytes, this becomes a
pleasant feature which looks and behaves like a memory leak :)
Ivan
The matter is that perl
it seems as if most (if not all) the techniques for checking the size of
the current process are _very_ platform specific. on linux you can use
Apache::SizeLimit::linux_size_check
which is just parsing /proc/self/status.
- mark
Stas Bekman wrote:
On Thu, 7 Dec 2000 [EMAIL PROTECTED]
On Fri, 8 Dec 2000, mark warren bracher wrote:
it seems as if most (if not all) the techniques for checking the size of
the current process are _very_ platform specific. on linux you can use
Apache::SizeLimit::linux_size_check
If you have linux you have (or can have GTop), which gives
On Fri, 8 Dec 2000, Stas Bekman wrote:
If you have linux you have (or can have GTop), which gives you an API to
do this and many other things. Apache::SizeLimit::linux_size_check is just
a custom function that you cannot really re-use (unless you put it into
some other module...
Today I discovered a strange behaiviour of perl,
and I wonder if anybody can tell me what to do with it.
The matter is that perl DOES NOT REUSE MEMORY allocated for
intermediate calculation results. This is specially harmful to
data-intensive modperl applications where one perl process
The output I get is
used memory = 0
used memory = 0
used memory = 0
used memory = 0
used memory = 0
I'm interested in how many leaks are possible in mod_perl
though because my mod_perl processes are getting bigger
with time -- about 200 requests is making the process
fatter by 1mb on the
On Thu, 7 Dec 2000, Ivan E. Panchenko wrote:
Today I discovered a strange behaiviour of perl,
and I wonder if anybody can tell me what to do with it.
The matter is that perl DOES NOT REUSE MEMORY allocated for
intermediate calculation results. This is specially harmful to
On Thu, 7 Dec 2000, Ivan E. Panchenko wrote:
Today I discovered a strange behaiviour of perl,
and I wonder if anybody can tell me what to do with it.
The matter is that perl DOES NOT REUSE MEMORY allocated for
intermediate calculation results. This is specially harmful to
data-intensive
Hi Ivan,
It's not really mod_perl, but is relevant to people on the list I guess...
If you really play aorund with this, you'll find some interesting variations.
If I assign $cc using a for loop
my $c;
for ( 1..2000) { $cc .= 'a'; }
it's a lot slower, but only
On Thu, 7 Dec 2000 [EMAIL PROTECTED] wrote:
The output I get is
used memory = 0
used memory = 0
used memory = 0
used memory = 0
used memory = 0
I get the same under perl 5.6.0 on linux, looks like BSD::Resource doesn't
work there :( Anyone?
Use gtop instead (if you have it):
use
You probably tried this script on linux or some other not fully BSD
compartible system. We obtained same zeros on linux, where getrusage()
means something else than on FreeBSD,
but if you try measuring memory sizes with ps or top, you should
observe the mentioned leak. Please insert sleep(10)
Hi again,
We managed to fix the problem described
below. The issue was the win32
porting code in perl. In the file
perl-5.6.0/win32/win32.h
commenting out the line:
#define ENV_IS_CASELESS
fixes the memory leak problem.
-harshy
-Original Message-
From: Harshy Wanigasekara
Greetings,
I am using Apache 1.3.9 on Linux kernel 2.0.36 using
ApacheASP wrapped around my CGI scripts. I have the following
test script which works fine unless I declare the array variable
"v" as "my @v". This causes massive memory consumption in that
much more memory is
Jim Turner wrote:
Greetings,
I am using Apache 1.3.9 on Linux kernel 2.0.36 using
ApacheASP wrapped around my CGI scripts. I have the following
test script which works fine unless I declare the array variable
"v" as "my @v". This causes massive memory consumption in that
much
On Mon, 11 Sep 2000, Stas Bekman wrote:
I was thinking about going thru the symbol table and dumping all the
variables. And run diff between the dumps of the two requests. Be careful
though that Devel::Peek doesn't show a complete dump for the whole
structure, and I couldn't find the
On Mon, 11 Sep 2000, Matt Sergeant wrote:
On Mon, 11 Sep 2000, Stas Bekman wrote:
I was thinking about going thru the symbol table and dumping all the
variables. And run diff between the dumps of the two requests. Be careful
though that Devel::Peek doesn't show a complete dump for the
On Mon, 11 Sep 2000, Stas Bekman wrote:
On Mon, 11 Sep 2000, Matt Sergeant wrote:
On Mon, 11 Sep 2000, Stas Bekman wrote:
I was thinking about going thru the symbol table and dumping all the
variables. And run diff between the dumps of the two requests. Be careful
though that
On Sun, 10 Sep 2000, Matt Sergeant wrote:
For 2 days solid now I've been trying to track down a very bizarre memory
leak in AxKit.
I've checked everything I can think of - all circular references are now
gone, all closures clean up carefully after themselves, and I've reduced
the usage
-Original Message-
From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 11, 2000 2:54 PM
To: Matt Sergeant
Cc: [EMAIL PROTECTED]
Subject: Re: Memory leak hell...
[snip]
look for xsubs in those modules you're using that are calling
new{SV,AV,HV,RV
For 2 days solid now I've been trying to track down a very bizarre memory
leak in AxKit.
I've checked everything I can think of - all circular references are now
gone, all closures clean up carefully after themselves, and I've reduced
the usage of some external modules. But still the processes
On Sun, 10 Sep 2000, Matt Sergeant wrote:
For 2 days solid now I've been trying to track down a very bizarre memory
leak in AxKit.
I've checked everything I can think of - all circular references are now
gone, all closures clean up carefully after themselves, and I've reduced
the usage
Matt Sergeant wrote:
Can anyone give me _any_ help in figuring out where this might be coming
from?
When I'm working on problems like this, there are two basic things I
try. They're not rocket science, but they usually work. The first is
removing sections of code until the leak goes away.
On Sun, 10 Sep 2000, Stas Bekman wrote:
On Sun, 10 Sep 2000, Matt Sergeant wrote:
For 2 days solid now I've been trying to track down a very bizarre memory
leak in AxKit.
I've checked everything I can think of - all circular references are now
gone, all closures clean up carefully
On Sun, 10 Sep 2000, Matt Sergeant wrote:
On Sun, 10 Sep 2000, Stas Bekman wrote:
On Sun, 10 Sep 2000, Matt Sergeant wrote:
For 2 days solid now I've been trying to track down a very bizarre memory
leak in AxKit.
I've checked everything I can think of - all circular
On Tue, 15 Aug 2000, vegan.star wrote:
I have some mod_perl modules. I suspect that it has a memory
leak. I'm running that in a Sun Solaris 2.6 machine with apache
1.3.9. I read that exists Apache::Leak to test for leaks.
How it works?
I have some packages and I put into them like
I have some mod_perl modules. I suspect that it has a memory
leak. I'm running that in a Sun Solaris 2.6 machine with apache
1.3.9. I read that exists Apache::Leak to test for leaks.
How it works?
I have some packages and I put into them like this:
package package_name;
use Apache::Leak
I'm having a memory leak problem that I suspect comes from a mod_perl
module of mine. The module talks to a MySQL database using DBI.
I can't see any memory hogs when I check the linux box with 'top',
but after several days the computer inevitably grinds to a halt.
This didn't happen before
Of course, the short term fix, is to lower MaxRequestsPerChild which
will hopefully reduce the leakage but won't help performance.
Leaks in DBD::Oracle and Oracle's own libraries are not entirely rare.
You should send your simple, stand-alone example to the dbi-user's
mailing list with your
Has anyone else come across a problem using DBD::Oracle, where
connect() leaks approximately 80k every time it is used (which, in my
case, is with every request child processes handle)? It's negligable with
regular perl scripts, but I've seen child sizes grow to 40 megs before I
killed them all.
On Fri, 7 Apr 2000, Nikki Chumakov wrote:
mod_perl probaly have memory leakage during rereading configs (e.g. on
the apachectl graceful)
do you have PerlFreshRestart On? if so, try turning it off. i think dso
leaks on restart too, try linking static if that's the problem. a static
httpd
Doug MacEachern wrote:
On Fri, 7 Apr 2000, Nikki Chumakov wrote:
mod_perl probaly have memory leakage during rereading configs (e.g. on
the apachectl graceful)
do you have PerlFreshRestart On? if so, try turning it off. i think dso
leaks on restart too, try linking static if that's
I have run into the same issue also both with mod_perl as a DSO module or
compiled staticly. I have tested it using apache-1.3.6 and apache-1.3.12
w/ mod_perl-1.22 and mod_perl-1.21. The memory growth also occurs if I
HUP the server rather than sending USR1. Since the problem only occurs if
mod_perl probaly have memory leakage during rereading configs (e.g. on
the apachectl graceful)
My system:
RH 6.1,
linux-2.2.15pre17
glibc-2.1
apache-1.3.12
mod_ssl-2.6.2
russian patches (ftp.lexa.ru/pub/apache-rus/) PL29.4
mm-1.0.12
mod_perl-1.22
With mod_perl module enabled in httpd.conf
and
MySQL 3.22.25 is used with Apache::DBI.
The major problem seems to be a memory leak of some sort, identical to that
described in the "memory leak in mod_perl" thread on this list from October
1997 and the "httpd, mod_perl and memory consumption (long)" thread from
Why, reinvent the wheel? I wrote Apache::VMonitor (grab from CPAN) that
does all this and more (all but tail -f) I use it all the time, saves me a
lot of time, since I don't have to telnet!
Ok - I will try to look into that when I get time.
2) Open up and hack Apache::SizeLimit and have
is used with Apache::DBI.
The major problem seems to be a memory leak of some sort, identical to
that
described in the "memory leak in mod_perl" thread on this list from
October
1997 and the "httpd, mod_perl and memory consumption (long)" thread from
July 1997.
[sn
with Apache::DBI.
The major problem seems to be a memory leak of some sort, identical to that
described in the "memory leak in mod_perl" thread on this list from October
1997 and the "httpd, mod_perl and memory consumption (long)" thread from
July 1997.
The server runs normal
Jan 2000 19:58:00 -
From: James Furness [EMAIL PROTECTED]
Reply-To: James Furness [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Memory leak/server crashes
I'm looking for some help getting apache to run reliably. Apache 1.3.9 with
mod_perl 1.21 and Perl 5.005_03 is running on a dual
Try using Apache::SizeLimit as a way of controlling your
processes. Sounds like a recursive page that performs infinite internal
requests.
Ok, sounds like a good solution, but it still seems to me I should be
eliminating the problem at the source. Any ideas as to how I could narrow
down the
gh traffic, and use a lot of CGI and
MySQL 3.22.25 is used with Apache::DBI.
The major problem seems to be a memory leak of some sort, identical to that
described in the "memory leak in mod_perl" thread on this list from October
1997 and the "httpd, mod_perl and memory consumption (long
]
Subject: Re: Memory leak/server crashes
Try using Apache::SizeLimit as a way of controlling your
processes. Sounds like a recursive page that performs infinite internal
requests.
Ok, sounds like a good solution, but it still seems to me I should be
eliminating the problem at the source
On Sun, 9 Jan 2000, Sean Chittenden wrote:
Yeah... two things I'd do:
1) Open two telnet sessions to the box. One for top that is
monitoring processes for your web user (www typically) and is sorting by
memory usage w/ a 1 second refresh. I'd change the size of the window
80 matches
Mail list logo
