You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Aaron Johnson <so...@gina.net> on 2001/04/04 22:48:42 UTC
Run away processes
Hello all,
Having some hard ( for me ) to track memory usage issues. We have moved
our production environment to a new machine with what we thought was
plenty of memory, but we seem to have an erratic bit of code somewhere
that eats all the available memory. We did not have this problem on our
previous machine, but it was running RH 6.1 and Perl 5.005 so by moving
to RH 7.0 and Perl 5.6 we have really asked for trouble.
My research shows that it might be in a search routine we have that
calls in Swish-E, but we can't get a consistent run away process when
testing.
In "the guide" it is recommended that a sub in the startup.pl file:
sub UNIVERSAL::AUTOLOAD {
my $class = shift;
warn "$class can't \$UNIVERSAL::AUTOLOAD!\n";
}
to trap undefined sub routines might help find the problem. I added
that code and now I am getting a laundry list of "bad" calls. Here is
just a short list:
Apache::ASP::Server=HASH(0x929ebc4) can't $UNIVERSAL::AUTOLOAD!
Apache::ASP::Collection=HASH(0x91d3374) can't $UNIVERSAL::AUTOLOAD!
Apache=SCALAR(0x8d61160) can't $UNIVERSAL::AUTOLOAD!
Apache::ASP::GlobalASA=HASH(0x91d31d0) can't $UNIVERSAL::AUTOLOAD!
Errno=ARRAY(0x8317564) can't $UNIVERSAL::AUTOLOAD!
DBI::DBI_tie=HASH(0x83d1d64) can't $UNIVERSAL::AUTOLOAD!
MLDBM::Serializer::Data::Dumper=HASH(0x917091c) can't
$UNIVERSAL::AUTOLOAD!
These are all repeated several times. I ran the same
UNIVERSAL::AUTOLOAD sub on another server and got very similar results (
the older RH 6.1 and Perl 5.005 one ) so it seems the errors might be
"normal" or at least under Apache::ASP.
So the summary of my setup is:
RH 7.0 ( with all RPM updates and new gcc )
Perl 5.6
Apache 1.3.19 compiled with the corrected gcc
mod_perl 1.25
Apache::ASP 2.09
If any more info is needed let me know.
Aaron Johnson
Re: Run away processes
Posted by ___cliff rayman___ <cl...@genwax.com>.
i think that it should be:
warn "\$class=$class can't \$UNIVERSAL::AUTOLOAD=$UNIVERSAL::AUTOLOAD!\n";
leads to less grepping and a quicker understanding of the problem.
--
___cliff rayman___cliff@genwax.com___http://www.genwax.com/
Aaron Johnson wrote:
> So should the entry in the Guide be rewritten to:
>
> sub UNIVERSAL::AUTOLOAD {
> my $class = shift;
> if ($UNIVERSAL::AUTOLOAD !~ /DESTROY$/) {
> warn "$class can't $UNIVERSAL::AUTOLOAD!\n";
> }
> }
>
> ??????
>
>
Re: Run away processes
Posted by Aaron Johnson <so...@gina.net>.
So should the entry in the Guide be rewritten to:
sub UNIVERSAL::AUTOLOAD {
my $class = shift;
if ($UNIVERSAL::AUTOLOAD !~ /DESTROY$/) {
warn "$class can't $UNIVERSAL::AUTOLOAD!\n";
}
}
??????
Tim Tompkins wrote:
> You don't need to trap DESTROY calls. But if you're defining an AUTOLOAD,
> you typically want to just return if the subroutine being called is DESTROY.
>
> Thanks,
>
> Tim Tompkins
> ----------------------------------------------
> Staff Engineer / Programmer
> http://www.arttoday.com/
> ----------------------------------------------
>
> ----- Original Message -----
> From: "Aaron Johnson" <so...@gina.net>
> To: <mo...@apache.org>
> Sent: Wednesday, April 04, 2001 2:48 PM
> Subject: Re: Run away processes
>
> > In a private email someone mentioned that removing the \ before the $
> might
> > make the messages more meaningful. That code was copy and pasted from the
> > current guide so if it should be $ and no \$ in front of UNIVERSAL then
> Stas
> > might want to know :^)
> >
> > I changed it out and now it appears that it is all the DESTROY calls that
> > are making its way to the error log. Should these be trapped some where
> > else?
> > I still don't think this has anything to do with my memory being consumed,
> > but I thought it seemed odd that so many things were called with no
> defined
> > sub.
> >
> > Aaron Johnson
> >
> > Aaron Johnson wrote:
> >
> > > Hello all,
> > >
> > > Having some hard ( for me ) to track memory usage issues. We have moved
> > > our production environment to a new machine with what we thought was
> > > plenty of memory, but we seem to have an erratic bit of code somewhere
> > > that eats all the available memory. We did not have this problem on our
> > > previous machine, but it was running RH 6.1 and Perl 5.005 so by moving
> > > to RH 7.0 and Perl 5.6 we have really asked for trouble.
> > >
> > > My research shows that it might be in a search routine we have that
> > > calls in Swish-E, but we can't get a consistent run away process when
> > > testing.
> > >
> > > In "the guide" it is recommended that a sub in the startup.pl file:
> > > sub UNIVERSAL::AUTOLOAD {
> > > my $class = shift;
> > > warn "$class can't \$UNIVERSAL::AUTOLOAD!\n";
> > > }
> > > to trap undefined sub routines might help find the problem. I added
> > > that code and now I am getting a laundry list of "bad" calls. Here is
> > > just a short list:
> > >
> > > Apache::ASP::Server=HASH(0x929ebc4) can't $UNIVERSAL::AUTOLOAD!
> > > Apache::ASP::Collection=HASH(0x91d3374) can't $UNIVERSAL::AUTOLOAD!
> > > Apache=SCALAR(0x8d61160) can't $UNIVERSAL::AUTOLOAD!
> > > Apache::ASP::GlobalASA=HASH(0x91d31d0) can't $UNIVERSAL::AUTOLOAD!
> > > Errno=ARRAY(0x8317564) can't $UNIVERSAL::AUTOLOAD!
> > > DBI::DBI_tie=HASH(0x83d1d64) can't $UNIVERSAL::AUTOLOAD!
> > > MLDBM::Serializer::Data::Dumper=HASH(0x917091c) can't
> > > $UNIVERSAL::AUTOLOAD!
> > >
> > > These are all repeated several times. I ran the same
> > > UNIVERSAL::AUTOLOAD sub on another server and got very similar results (
> > > the older RH 6.1 and Perl 5.005 one ) so it seems the errors might be
> > > "normal" or at least under Apache::ASP.
> > >
> > > So the summary of my setup is:
> > > RH 7.0 ( with all RPM updates and new gcc )
> > > Perl 5.6
> > > Apache 1.3.19 compiled with the corrected gcc
> > > mod_perl 1.25
> > > Apache::ASP 2.09
> > >
> > > If any more info is needed let me know.
> > >
> > > Aaron Johnson
> >
> >
Re: Run away processes
Posted by Tim Tompkins <ti...@arttoday.com>.
You don't need to trap DESTROY calls. But if you're defining an AUTOLOAD,
you typically want to just return if the subroutine being called is DESTROY.
Thanks,
Tim Tompkins
----------------------------------------------
Staff Engineer / Programmer
http://www.arttoday.com/
----------------------------------------------
----- Original Message -----
From: "Aaron Johnson" <so...@gina.net>
To: <mo...@apache.org>
Sent: Wednesday, April 04, 2001 2:48 PM
Subject: Re: Run away processes
> In a private email someone mentioned that removing the \ before the $
might
> make the messages more meaningful. That code was copy and pasted from the
> current guide so if it should be $ and no \$ in front of UNIVERSAL then
Stas
> might want to know :^)
>
> I changed it out and now it appears that it is all the DESTROY calls that
> are making its way to the error log. Should these be trapped some where
> else?
> I still don't think this has anything to do with my memory being consumed,
> but I thought it seemed odd that so many things were called with no
defined
> sub.
>
> Aaron Johnson
>
> Aaron Johnson wrote:
>
> > Hello all,
> >
> > Having some hard ( for me ) to track memory usage issues. We have moved
> > our production environment to a new machine with what we thought was
> > plenty of memory, but we seem to have an erratic bit of code somewhere
> > that eats all the available memory. We did not have this problem on our
> > previous machine, but it was running RH 6.1 and Perl 5.005 so by moving
> > to RH 7.0 and Perl 5.6 we have really asked for trouble.
> >
> > My research shows that it might be in a search routine we have that
> > calls in Swish-E, but we can't get a consistent run away process when
> > testing.
> >
> > In "the guide" it is recommended that a sub in the startup.pl file:
> > sub UNIVERSAL::AUTOLOAD {
> > my $class = shift;
> > warn "$class can't \$UNIVERSAL::AUTOLOAD!\n";
> > }
> > to trap undefined sub routines might help find the problem. I added
> > that code and now I am getting a laundry list of "bad" calls. Here is
> > just a short list:
> >
> > Apache::ASP::Server=HASH(0x929ebc4) can't $UNIVERSAL::AUTOLOAD!
> > Apache::ASP::Collection=HASH(0x91d3374) can't $UNIVERSAL::AUTOLOAD!
> > Apache=SCALAR(0x8d61160) can't $UNIVERSAL::AUTOLOAD!
> > Apache::ASP::GlobalASA=HASH(0x91d31d0) can't $UNIVERSAL::AUTOLOAD!
> > Errno=ARRAY(0x8317564) can't $UNIVERSAL::AUTOLOAD!
> > DBI::DBI_tie=HASH(0x83d1d64) can't $UNIVERSAL::AUTOLOAD!
> > MLDBM::Serializer::Data::Dumper=HASH(0x917091c) can't
> > $UNIVERSAL::AUTOLOAD!
> >
> > These are all repeated several times. I ran the same
> > UNIVERSAL::AUTOLOAD sub on another server and got very similar results (
> > the older RH 6.1 and Perl 5.005 one ) so it seems the errors might be
> > "normal" or at least under Apache::ASP.
> >
> > So the summary of my setup is:
> > RH 7.0 ( with all RPM updates and new gcc )
> > Perl 5.6
> > Apache 1.3.19 compiled with the corrected gcc
> > mod_perl 1.25
> > Apache::ASP 2.09
> >
> > If any more info is needed let me know.
> >
> > Aaron Johnson
>
>
Re: Run away processes
Posted by Aaron Johnson <so...@gina.net>.
In a private email someone mentioned that removing the \ before the $ might
make the messages more meaningful. That code was copy and pasted from the
current guide so if it should be $ and no \$ in front of UNIVERSAL then Stas
might want to know :^)
I changed it out and now it appears that it is all the DESTROY calls that
are making its way to the error log. Should these be trapped some where
else?
I still don't think this has anything to do with my memory being consumed,
but I thought it seemed odd that so many things were called with no defined
sub.
Aaron Johnson
Aaron Johnson wrote:
> Hello all,
>
> Having some hard ( for me ) to track memory usage issues. We have moved
> our production environment to a new machine with what we thought was
> plenty of memory, but we seem to have an erratic bit of code somewhere
> that eats all the available memory. We did not have this problem on our
> previous machine, but it was running RH 6.1 and Perl 5.005 so by moving
> to RH 7.0 and Perl 5.6 we have really asked for trouble.
>
> My research shows that it might be in a search routine we have that
> calls in Swish-E, but we can't get a consistent run away process when
> testing.
>
> In "the guide" it is recommended that a sub in the startup.pl file:
> sub UNIVERSAL::AUTOLOAD {
> my $class = shift;
> warn "$class can't \$UNIVERSAL::AUTOLOAD!\n";
> }
> to trap undefined sub routines might help find the problem. I added
> that code and now I am getting a laundry list of "bad" calls. Here is
> just a short list:
>
> Apache::ASP::Server=HASH(0x929ebc4) can't $UNIVERSAL::AUTOLOAD!
> Apache::ASP::Collection=HASH(0x91d3374) can't $UNIVERSAL::AUTOLOAD!
> Apache=SCALAR(0x8d61160) can't $UNIVERSAL::AUTOLOAD!
> Apache::ASP::GlobalASA=HASH(0x91d31d0) can't $UNIVERSAL::AUTOLOAD!
> Errno=ARRAY(0x8317564) can't $UNIVERSAL::AUTOLOAD!
> DBI::DBI_tie=HASH(0x83d1d64) can't $UNIVERSAL::AUTOLOAD!
> MLDBM::Serializer::Data::Dumper=HASH(0x917091c) can't
> $UNIVERSAL::AUTOLOAD!
>
> These are all repeated several times. I ran the same
> UNIVERSAL::AUTOLOAD sub on another server and got very similar results (
> the older RH 6.1 and Perl 5.005 one ) so it seems the errors might be
> "normal" or at least under Apache::ASP.
>
> So the summary of my setup is:
> RH 7.0 ( with all RPM updates and new gcc )
> Perl 5.6
> Apache 1.3.19 compiled with the corrected gcc
> mod_perl 1.25
> Apache::ASP 2.09
>
> If any more info is needed let me know.
>
> Aaron Johnson
Re: Run away processes
Posted by Stas Bekman <st...@stason.org>.
On Wed, 4 Apr 2001, Ken Williams wrote:
> solution@gina.net (Aaron Johnson) wrote:
> >In "the guide" it is recommended that a sub in the startup.pl file:
> >sub UNIVERSAL::AUTOLOAD {
> > my $class = shift;
> > warn "$class can't \$UNIVERSAL::AUTOLOAD!\n";
> > }
>
> You'll get more useful information if you get rid of the backslash:
>
> sub UNIVERSAL::AUTOLOAD {
> my $class = shift;
> warn "$class can't $UNIVERSAL::AUTOLOAD!\n";
> }
>
> Stas - this should be changed in the guide, on the
> 'All_RAM_Consumed.html' page.
fixed. thanks!
> My guess at your problem - you haven't pre-loaded all necessary modules
> in your startup files (httpd.conf and startup.pl). The code is
> disappearing when the children die and are re-spawned.
>
>
> ------------------- -------------------
> Ken Williams Last Bastion of Euclidity
> ken@forum.swarthmore.edu The Math Forum
>
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Run away processes
Posted by Ken Williams <ke...@forum.swarthmore.edu>.
solution@gina.net (Aaron Johnson) wrote:
>In "the guide" it is recommended that a sub in the startup.pl file:
>sub UNIVERSAL::AUTOLOAD {
> my $class = shift;
> warn "$class can't \$UNIVERSAL::AUTOLOAD!\n";
> }
You'll get more useful information if you get rid of the backslash:
sub UNIVERSAL::AUTOLOAD {
my $class = shift;
warn "$class can't $UNIVERSAL::AUTOLOAD!\n";
}
Stas - this should be changed in the guide, on the
'All_RAM_Consumed.html' page.
My guess at your problem - you haven't pre-loaded all necessary modules
in your startup files (httpd.conf and startup.pl). The code is
disappearing when the children die and are re-spawned.
------------------- -------------------
Ken Williams Last Bastion of Euclidity
ken@forum.swarthmore.edu The Math Forum