Re: The apache CPU race..
i've seen stuff like this on osx a lot -- apache or some other app will peg for near 100% cpu use for a few moments, then just go idle no idea why. there's a VERY good chance this is a mac thing, and your code will be fine on another server (assuming you're using the mac like me as a dev box for eventual install on freebsd/linux mchines) On Dec 6, 2005, at 12:36 AM, Fredrik Lindmark wrote: PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 548 httpd 73.3% 0:45.79 6291 404 26.5M 44.6M 32.4M 110M 547 httpd0.0% 0:00.00 1 9 231 5.81M 39.1M 708K 59.6M This is the status aprox. 40 sec after the last page was delivered. (if i turn off other stuff running here it goes towards 100% consuming.) Around 60s after last page was done the process knocks it off and goes back to idle... I kinda hope for a bit more traffic than 1 per min.. so any help would be appreciated. darwin 10.3.9 / apache 2.2.0 w/ worker / mod_perl 2.0.2 / perl 5.8.1 Had same issue on the apache 2.0.55 version in fact... ~ F
Re: The apache CPU race..
Hey Jonathan, yep. thats the idea.. just that our server network consists of osx-servers as well... so im not getting around it that easy =/ Was searching around but couldnt pick up any bug-report of this kind It's no loop, cause i get the confirmation the page is done and the script is terminated.. And im not starting up new threads myself.. i rely on apache on this so it feels like i should be in a safe enviroment here.. no work should be left after the page is done. the only thing that can distrub is the fact im sharing memory over threads. But its should only be work for the CPU while im running the page.. not afterwards, right? deadlocks should stop me in the middle.. and not progress to the end.. so it sounds distant. A memory leakage wouldnt torture the cpu like this afaik, just show up as a climbing number on the memory display so .. feels like im innocent here.. although it does seems like its just some few big size operations that triggers it, wich indikates that some rutine can be the cause... thats about as far as i got in the analyze.. i'll try to isolate it a bit futher, could be some plugin even though it sounds odd. ~ F On Dec 6, 2005, at 2:24 PM, Jonathan Vanasco wrote: i've seen stuff like this on osx a lot -- apache or some other app will peg for near 100% cpu use for a few moments, then just go idle no idea why. there's a VERY good chance this is a mac thing, and your code will be fine on another server (assuming you're using the mac like me as a dev box for eventual install on freebsd/linux mchines) On Dec 6, 2005, at 12:36 AM, Fredrik Lindmark wrote: PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 548 httpd 73.3% 0:45.79 6291 404 26.5M 44.6M 32.4M 110M 547 httpd0.0% 0:00.00 1 9 231 5.81M 39.1M 708K 59.6M This is the status aprox. 40 sec after the last page was delivered. (if i turn off other stuff running here it goes towards 100% consuming.) Around 60s after last page was done the process knocks it off and goes back to idle... I kinda hope for a bit more traffic than 1 per min.. so any help would be appreciated. darwin 10.3.9 / apache 2.2.0 w/ worker / mod_perl 2.0.2 / perl 5.8.1 Had same issue on the apache 2.0.55 version in fact... ~ F
Re: Strange APR::UUID Issue on OpenBSD in Makeifle.PL
Christopher H. Laco wrote:
> I'm headed out for the day, so I apologize for the email-and -un. I
> posted this last night to PerlMonks, and I'll post it to the EU::MM list
> when I get home:
>
> http://perlmonks.org/?node_id=513773
>
> Long story short, I got reports that perl Makefile.PL for my dist was
> producing a 0 byte Makefile. After whittling it down, I found that any
> encantation of use/require/eval ''/eval{} of APR::UUID in my Makefile.PL
> was causing ExtUtils::MakeMaker to spit out a 0 byte Makefile; only on
> OpenBSD. Linux/FreeBSD/win32 worked fine.
>
> Removing the probe for APR::UUID solved the problem.
>
> At this point, I have no idea what is going on, or even where the
> problem is (EU::MM, Perl, XS, or APR::UUID). Someone on #catalyst
> mentioned that there are Config/dl_load/ ne 'openbsd' bits in APR.xs
> that may or maynot be just a coincedence.
>
> Anyone else have any ideas?
>
> When I get home, I'm going to make a bare bones dist and Makefile.PL for
> testing purposes. Luckily, the reporter of the problem was kind enough
> to seutp a test account for my on the mahcine in question.
>
> It has MP 2.0.2, OpenBSD 3.8 RELEASE, perl 5.8.6, and EU::MM 6.30.
>
> Thanks,
> -=Chris
Just to keep the list up to date, and recap what has been found:
The following Makefile.PL produces a 0 byte Makefile under MP2.0.2,
OpenBSD 3.8-RELEASE, perl 5.8.6:
> use ExtUtils::MakeMaker;
> use APR;
> my $r = WriteMakefile(
> NAME => 'Handel',
> VERSION_FROM => 'lib/Handel.pm',
> AUTHOR => 'Christopher H. Laco',
> ABSTRACT => 'Simple ecommerce framework',
> );
On a whim that it might be a double loading of APR issue between
Makefile.PL, and EU::MM eval-ing my Handel.pm, I changed the Makefile.PL
to this:
> use ExtUtils::MakeMaker;
> use APR;
> my $r = WriteMakefile(
> NAME => 'Handel',
> VERSION => '0.28',
> AUTHOR => 'Christopher H. Laco',
> ABSTRACT => 'Simple ecommerce framework',
> );
That still creates a 0 byte Makefile.
Adding a print statement to this makes it work:
> use ExtUtils::MakeMaker;
> use APR;
> print 'foo';
> my $r = WriteMakefile(
> NAME => 'Handel',
> VERSION_FROM => 'lib/Handel.pm',
> AUTHOR => 'Christopher H. Laco',
> ABSTRACT => 'Simple ecommerce framework',
> );
Just to reinforce that notion, if I add this to APR.pm:
> BEGIN {warn 'using custom APR'};
I get the full Makefile.
Commenting out:
> sub dl_load_flags { DL_GLOBAL }
or it's use constant DL_GLOBAL has an effect on the problem.
No incantations of use/require, eval{}. eval '' solve the problem.
I've also noted that I have massive SQlite test failures on this box
with things like:
> DBD::SQLite::db do failed: database is full(1) at dbdimp.c
> DBD::SQLite::db do failed: database schema has changed(1)
> DBD::SQLite::db do failed: no such table:
that immediately went away when I removed use APR from my main module.
...only on OpenBSD.
At this point, the level of magic required to further identify and fix
this issue is way above my skill level. Unless anyone has any further
ideas, it looks like I need to refrain from using APR [outside of
Apache/MP] in this platform.
My real concern is what else XS/IO related is borked in this kind of
scnerio...
Thanks,
-=Chris
smime.p7s
Description: S/MIME Cryptographic Signature
Re: The apache CPU race..
On Tue, 6 Dec 2005 16:58:49 -0200 Fredrik Lindmark <[EMAIL PROTECTED]> wrote: > Hey Jonathan, > > yep. thats the idea.. just that our server network consists of > osx-servers as well... so im not getting around it that easy =/ > Was searching around but couldnt pick up any bug-report of this kind > > It's no loop, cause i get the confirmation the page is done and the > script is terminated.. > And im not starting up new threads myself.. i rely on apache on this > so it feels like i should be in a safe enviroment here.. Have you tried the same code with the prefork MPM? While I know there are people using the other MPMs, prefork is by far the most used and tested with mod_perl. - Frank Wiles <[EMAIL PROTECTED]> http://www.wiles.org -
Re: The apache CPU race..
On Dec 6, 2005, at 7:00 PM, Frank Wiles wrote: And im not starting up new threads myself.. i rely on apache on this so it feels like i should be in a safe enviroment here.. Have you tried the same code with the prefork MPM? While I know there are people using the other MPMs, prefork is by far the most used and tested with mod_perl. Was running prefork apache 2.0.52 earlier. without any of these symptoms.. Im switching to the worker in an attempt to improve the performance, adding memory sharing .. the code is no big difference apart from the earlier though, therefore i believe the error is related to the worker MPM alone. It wont actually help my cause to switch back, it need to be multi-threaded... yet it might take me closer to a better filed bug-report.. so tx, good point. ~ F
Re: apache2::upload with reverse_proxy
Srebrenko Sehic wrote: There is a bug introduced in Apache 2.0.55 which breaks mod_proxy in various ways with POST data. Try 2.0.54 and see if that helps. Yes thanks very much that was the problem. I installed 2.2.0 as the front_end and works fine. Scott On 12/5/05, Scott Alexander <[EMAIL PROTECTED]> wrote: Hi, I did have two seperate machines in my test environment. A lite weight front end with just apache2 and a back end with mod_perl. File uploads worked fine using apache2::upload Now I have a front_end and mod_perl on the same machine but file uploads stopped working front_end with just one machine is Apache/2.0.55 (Unix) mod_ssl/2.0.55 OpenSSL/0.9.8a and the back_end on the same machine is Apache/2.0.55 (Unix) DAV/2 PHP/4.4.1 mod_apreq2-20050712/2.1.3-dev mod_perl/2.0.2 Perl/v5.8.5 Now when I try to upload a file it doesn't work. I get no errors in either logs files. What is the reason for it to stop working? Both apache process are running as same user 'nobody' Regards Scott
