You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Pier Fumagalli <pi...@betaversion.org> on 2002/06/11 16:29:17 UTC
Worker + MaxClient ...
I just recompiled the latest HEAD on nagoya, and doing some performance
analysis.... One thing I noticed is that when someone hits "MaxClients",
performances go down to be dog-slow... IIRC, this was a known bug of Worker,
but wasn't it supposed to be fixed?
I'm currently trying it out with a 64-bits compiled binary, but will do the
same once the 32-bits one gets baked... It just looks really weird..
Pier
Re: Worker + MaxClient ...
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Aaron Bannert" <aa...@clove.org> wrote:
> On Tue, Jun 11, 2002 at 06:35:15PM +0100, Pier Fumagalli wrote:
>>> From time to time, 3 times over 10k requests today for manual/index.html,
>> 2.0.38-dev as of this morning segfaults when it is compiled at 64bits under
>> Solaris-8, with lightweight processes used instead of threads, and
>> concurrency greater than 1000...
>
> ...
>> The relevant part of the configuration are:
>>
>> StartServers 4
>> ThreadLimit 256
>> ThreadsPerChild 256
>> MaxRequestsPerChild 0
>
> Are you maybe just running out of process slots? The /usr/lib/lwp/ thread
> library guarantees that you'll use 4*256 process slots right off the bat,
> where the default /usr/lib library will ramp up over time.
Don't think so... That machine was a mail server for our newsletters (1/2
mil deliveries a day), running qmail, and the concurrency-remote was 1024,
and I never had a problem...
Also, what's wicked is that it only happens when the thing is compiled at 64
bits... At 32 it crawls, but it's still up, and the configuration is the
same. If it was a problem of slots, it would fail in the same way both at 32
or 64...
Plus, in theory, if Apache is unable is not able to create a child (process
or thread), doesn't it report it? It shouldn't segfault for that, right?
Just out of curiosity (I want to doublecheck) how do I increase it on
Solaris 8?
Pier
Re: Worker + MaxClient ...
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Jun 11, 2002 at 06:35:15PM +0100, Pier Fumagalli wrote:
> >From time to time, 3 times over 10k requests today for manual/index.html,
> 2.0.38-dev as of this morning segfaults when it is compiled at 64bits under
> Solaris-8, with lightweight processes used instead of threads, and
> concurrency greater than 1000...
...
> The relevant part of the configuration are:
>
> StartServers 4
> ThreadLimit 256
> ThreadsPerChild 256
> MaxRequestsPerChild 0
Are you maybe just running out of process slots? The /usr/lib/lwp/ thread
library guarantees that you'll use 4*256 process slots right off the bat,
where the default /usr/lib library will ramp up over time.
-aaron
Re: Worker + MaxClient ...
Posted by Brian Pane <br...@cnet.com>.
Pier Fumagalli wrote:
>>From time to time, 3 times over 10k requests today for manual/index.html,
>2.0.38-dev as of this morning segfaults when it is compiled at 64bits under
>Solaris-8, with lightweight processes used instead of threads, and
>concurrency greater than 1000...
>
>But it didn't dump the core, so, can't do much with it (still need to find
>out all those nice CC flags for Sun's compilers)...
>
If you want to catch it just before it crashes, truss -M should work:
truss -f -Mall -t\!all -p {pids of the worker parent and children}
This will pause any httpd process that's just experienced a memory fault,
so you can attach a debugger to the process while it's still alive.
--Brian
Re: Worker + MaxClient ...
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Pier Fumagalli" <pi...@betaversion.org> wrote:
> I just recompiled the latest HEAD on nagoya, and doing some performance
> analysis.... One thing I noticed is that when someone hits "MaxClients",
> performances go down to be dog-slow... IIRC, this was a known bug of Worker,
> but wasn't it supposed to be fixed?
>
> I'm currently trying it out with a 64-bits compiled binary, but will do the
> same once the 32-bits one gets baked... It just looks really weird..
>From time to time, 3 times over 10k requests today for manual/index.html,
2.0.38-dev as of this morning segfaults when it is compiled at 64bits under
Solaris-8, with lightweight processes used instead of threads, and
concurrency greater than 1000...
But it didn't dump the core, so, can't do much with it (still need to find
out all those nice CC flags for Sun's compilers)...
BTW, when running with the default threading library, it works just fine.
Here are some results of the tests... The machine is an E450 with 10 Mbps of
network, 1 gig ram, and 2 UltraSPARC/II-400 processors... The remote client
is an ultra 5 connected on the same hub...
The relevant part of the configuration are:
StartServers 4
ThreadLimit 256
ThreadsPerChild 256
MaxRequestsPerChild 0
Then it's all default... Have fun...
--- 64 BIT REMOTE -----------------------------------------
Concurrency Level: 1000
Total transferred: 104587192 bytes
Requests per second: 89.47 [#/sec] (mean)
Transfer rate: 935.73 [Kbytes/sec] received
Concurrency Level: 100
Total transferred: 103015852 bytes
Requests per second: 95.86 [#/sec] (mean)
Transfer rate: 987.51 [Kbytes/sec] received
--- 32 BIT REMOTE -----------------------------------------
Concurrency Level: 1000
Total transferred: 104265004 bytes
Requests per second: 92.75 [#/sec] (mean)
Transfer rate: 967.06 [Kbytes/sec] received
Concurrency Level: 100
Total transferred: 102898755 bytes
Requests per second: 96.28 [#/sec] (mean)
Transfer rate: 990.75 [Kbytes/sec] received
--- 64 BIT LOCAL ------------------------------------------
Concurrency Level: 100
Total transferred: 102840000 bytes
Requests per second: 538.77 [#/sec] (mean)
Transfer rate: 5410.81 [Kbytes/sec] received
Concurrency Level: 100 (LWP)
Total transferred: 102840000 bytes
Requests per second: 482.60 [#/sec] (mean)
Transfer rate: 4846.72 [Kbytes/sec] received
Concurrency Level: 1000
Total transferred: 102840000 bytes
Requests per second: 95.62 [#/sec] (mean)
Transfer rate: 960.35 [Kbytes/sec] received
Concurrency Level: 1000 (LWP) [Segmentation fault]
Total transferred: 102840000 bytes
Requests per second: 99.77 [#/sec] (mean)
Transfer rate: 1001.95 [Kbytes/sec] received
--- 32 BIT LOCAL ------------------------------------------
Concurrency Level: 100
Total transferred: 102730000 bytes
Requests per second: 522.13 [#/sec] (mean)
Transfer rate: 5238.06 [Kbytes/sec] received
Concurrency Level: 100 (LWP)
Total transferred: 102730000 bytes
Requests per second: 547.79 [#/sec] (mean)
Transfer rate: 5495.51 [Kbytes/sec] received
Concurrency Level: 1000
Total transferred: 102730000 bytes
Requests per second: 91.36 [#/sec] (mean)
Transfer rate: 916.54 [Kbytes/sec] received
Concurrency Level: 1000 (LWP)
Total transferred: 102730000 bytes
Requests per second: 99.43 [#/sec] (mean)
Transfer rate: 997.46 [Kbytes/sec] received
Pier