You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Jon Molin <Jo...@resfeber.se> on 2002/01/25 14:09:05 UTC
Tracing script with problem
Hi list,
I had problems with a script that went nuts and took 65MB memory and
alot of cpu. To track this script down I thought Apache:VMonitor would
be perfect, unfortenately I ran into some weird promlems (it said there
was an error in mod_perl.h) and i know gcc might be broken on this
machine so I started scratching my head and came to the conclusion that
this 'oneliner' ought to help me track the error down:
find /www/docs -name '*.cgi' -type f -exec perl -pi -e
's:(#!/usr/bin/perl[ w-]*\s*):$1\nprint STDERR "\\nPID=\$\$
SCRIPT=\$ENV{REQUEST_URI} \\n";\n:s;' {} \;
ie, every script now prints it's httpd pid and it's request_uri. So i
just started waiting watching top with excitment and when the 65 MB
httpd process i greped for the pid in the error_log and got the
scriptname and it's arguments.
Then i reproduced the error on a server with VMonitor to see if what i
missed out. Ok i could see the name of the scrpit but the real problem
was with the query_string, choped after a couple of chars. Now, if i
understand things right (i tried some tweaking on the module) it's not
possible to get more than 64 char. Why is this, and is it really so?
I know I'm no Einstein and i presume thousands of ppl have tried tracing
similar problems, how did you do it? There must be a more effective way
to find it? I know I would've got the script name but since i never
thought it would get the input it got chances are it'd take me a long
time finding the problem if i only knew the name.
/Jon
Re: Tracing script with problem
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
[snip]
> >
> > Another question, do you (or anyone else for that matter) know how the
> > accesslog works? (and also why it does work like it does) It seems it
> > prints after the request is done, otherwise could that easily be used
> > for checking the parameters, and not only loging.
>
> You probably need to read some docs, which explain how can specify your
> own access log format or supply your own log handler.
>
> For using the standard Apache formats see the docs at apache.org (you
> also have them installed together with Apache under 'manual' dir on your
> machine. For mod_perl examples you should probably see the eagle book,
> check www.modperl.com (which seems to be offline now) if it has the
> relevant chapters online, I think it's chapters 7 and 9 that you want.
>
> The guide has some info here:
> http://thingy.kcilink.com/cgi-bin/modperlguide.cgi?q=PerlLogHandler
our chapter on logging and the PerlLogHandler also happens to be online :)
http://www.modperlcookbook.org/chapters/ch16.pdf
--Geoff
Re: Tracing script with problem
Posted by Stas Bekman <st...@stason.org>.
Jon Molin wrote:
> Stas Bekman wrote:
>
>>It's actually easy, take a look at the Apache::SizeLimit or
>>Apache::GTopLimit, look at the cleanup handler that they register. Now
>>take this handler and dump whatever you need to the file or error_log
>>when you find that the process was taking too much memory.
>>
>>Take a look at this code and you will see that it's very simple.
>>
>>
>
> Thanks a bunch, I'll look into that.
>
> Another question, do you (or anyone else for that matter) know how the
> accesslog works? (and also why it does work like it does) It seems it
> prints after the request is done, otherwise could that easily be used
> for checking the parameters, and not only loging.
You probably need to read some docs, which explain how can specify your
own access log format or supply your own log handler.
For using the standard Apache formats see the docs at apache.org (you
also have them installed together with Apache under 'manual' dir on your
machine. For mod_perl examples you should probably see the eagle book,
check www.modperl.com (which seems to be offline now) if it has the
relevant chapters online, I think it's chapters 7 and 9 that you want.
The guide has some info here:
http://thingy.kcilink.com/cgi-bin/modperlguide.cgi?q=PerlLogHandler
_____________________________________________________________________
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://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Tracing script with problem
Posted by Jon Molin <Jo...@resfeber.se>.
Stas Bekman wrote:
>
> It's actually easy, take a look at the Apache::SizeLimit or
> Apache::GTopLimit, look at the cleanup handler that they register. Now
> take this handler and dump whatever you need to the file or error_log
> when you find that the process was taking too much memory.
>
> Take a look at this code and you will see that it's very simple.
>
Thanks a bunch, I'll look into that.
Another question, do you (or anyone else for that matter) know how the
accesslog works? (and also why it does work like it does) It seems it
prints after the request is done, otherwise could that easily be used
for checking the parameters, and not only loging.
/Jon
> _____________________________________________________________________
> 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://ticketmaster.com http://apacheweek.com
> http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Tracing script with problem
Posted by Stas Bekman <st...@stason.org>.
Jon Molin wrote:
> Hi list,
>
> I had problems with a script that went nuts and took 65MB memory and
> alot of cpu. To track this script down I thought Apache:VMonitor would
> be perfect, unfortenately I ran into some weird promlems (it said there
> was an error in mod_perl.h) and i know gcc might be broken on this
> machine so I started scratching my head and came to the conclusion that
> this 'oneliner' ought to help me track the error down:
>
> find /www/docs -name '*.cgi' -type f -exec perl -pi -e
> 's:(#!/usr/bin/perl[ w-]*\s*):$1\nprint STDERR "\\nPID=\$\$
> SCRIPT=\$ENV{REQUEST_URI} \\n";\n:s;' {} \;
>
> ie, every script now prints it's httpd pid and it's request_uri. So i
> just started waiting watching top with excitment and when the 65 MB
> httpd process i greped for the pid in the error_log and got the
> scriptname and it's arguments.
>
> Then i reproduced the error on a server with VMonitor to see if what i
> missed out. Ok i could see the name of the scrpit but the real problem
> was with the query_string, choped after a couple of chars. Now, if i
> understand things right (i tried some tweaking on the module) it's not
> possible to get more than 64 char. Why is this, and is it really so?
it's the limitation from apache scoreboard, it gives us only 64 chars. I
don't think this is going to change this scoreboard must be very light
and not to add an overhead to requests.
> I know I'm no Einstein and i presume thousands of ppl have tried tracing
> similar problems, how did you do it? There must be a more effective way
> to find it? I know I would've got the script name but since i never
> thought it would get the input it got chances are it'd take me a long
> time finding the problem if i only knew the name.
It's actually easy, take a look at the Apache::SizeLimit or
Apache::GTopLimit, look at the cleanup handler that they register. Now
take this handler and dump whatever you need to the file or error_log
when you find that the process was taking too much memory.
Take a look at this code and you will see that it's very simple.
_____________________________________________________________________
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://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/