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
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
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
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
[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
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
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
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
Re: Run away processes
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. -- greg
Re: Run away processes
On Mon, 17 Jan 2000, Bill Moseley 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? how is it 'running away' exactly? any insight with strace or gdb? as of 1.3.6, scripts should be able to continue on after the connection is broken and apache i/o functions become noops (they don't bother trying to write to the socket). does it help if you add to httpd.conf: PerlFixupHandler Apache::SIG ?
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]
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
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]