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
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
[EMAIL PROTECTED] (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
[EMAIL PROTECTED]The Math Forum
Re: Run away processes
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" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
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
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" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
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
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 [EMAIL PROTECTED]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
On Wed, 4 Apr 2001, Ken Williams wrote:
[EMAIL PROTECTED] (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
[EMAIL PROTECTED]The Math Forum
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Run away processes
On 20 Jan 2000, Greg Stark wrote: Stas Bekman [EMAIL PROTECTED] writes: Is there a recommendation on how to catch stop run away mod_perl programs in a way that's _not_ part of the run away program. Or is this even possible? Some type of watchdog, just like httpd.conf Timeout? Try Apache::SafeHang http://www.singlesheaven.com/stas/modules/Apache-SafeHang-0.01.tar.gz Runaway? you mean 100% CPU ? Set up Apache::Resource then. This isn't related to Oracle by any chance is it? We had this problem inside the Oracle libs at one point. The process can be "runaway" waiting for some event to happen, or not to complete for some other reason. It might use 0% CPU in this case and untrappable by Apache::Resource. I've showen a few examples in the debug chapter of the guide. ___ Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
Run away processes
The httpd.conf Timeout setting doesn't effect mod_perl, it seems, even if the client breaks the connection. Is there a recommendation on how to catch stop run away mod_perl programs in a way that's _not_ part of the run away program. Or is this even possible? Some type of watchdog, just like httpd.conf Timeout? Thanks, Bill Moseley mailto:[EMAIL PROTECTED]
Re: Run away processes
The httpd.conf Timeout setting doesn't effect mod_perl, it seems, even if the client breaks the connection. Is there a recommendation on how to catch stop run away mod_perl programs in a way that's _not_ part of the run away program. Or is this even possible? Some type of watchdog, just like httpd.conf Timeout? Try Apache::SafeHang http://www.singlesheaven.com/stas/modules/Apache-SafeHang-0.01.tar.gz It should be renamed one day when I get back to work on it, into something like Apache::Watchdog::RunAwayProc as kindly was suggested by Ken Williams (the Apache::Watchdog:: part :) ___ Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
Re: Run away processes
At 06:48 PM 1/17/00 +0200, Stas Bekman wrote: The httpd.conf Timeout setting doesn't effect mod_perl, it seems, even if the client breaks the connection. Is there a recommendation on how to catch stop run away mod_perl programs in a way that's _not_ part of the run away program. Or is this even possible? Some type of watchdog, just like httpd.conf Timeout? Try Apache::SafeHang http://www.singlesheaven.com/stas/modules/Apache-SafeHang-0.01.tar.gz Oh, ya. Thanks. I'm curious. What is the reason Timeout doesn't work? Does Timeout only work with mod_cgi? Bill Moseley mailto:[EMAIL PROTECTED]
