> I've found a (to me) unexplicable system behaviour when the number of
> Apache forked instances goes somewhere beyond 1050, the machine
> suddently slows down almost top a halt and becomes totally unresponsive,
> until I stop the test (SpecWeb).
Im suprised it gets that far
> Moreover the max
I've found a (to me) unexplicable system behaviour when the number of
Apache forked instances goes somewhere beyond 1050, the machine
suddently slows down almost top a halt and becomes totally unresponsive,
until I stop the test (SpecWeb).
Im suprised it gets that far
Moreover the max
On 29-Mar-01 Fabio Riccardi wrote:
> Hello,
>
> I'm working on an enhanced version of Apache and I'm hitting my head
> against something I don't understand.
>
> I've found a (to me) unexplicable system behaviour when the number of
> Apache forked instances goes somewhere beyond 1050, the
Hi Mike,
somebody else on the list already pointed me at your stuff and I quickly
downloaded your multiqueue patch for 2.4.1 to try it out.
It works great! I finally manage to have 100% CPU utilization and keep the
machine decently responsive.
On a two 1GHz pentium box i went from 1300 specweb
On Thu, Mar 29, 2001 at 01:55:11PM -0800, Fabio Riccardi wrote:
> I'm using 2.4.2-ac26, but I've noticed the same behavior with all the 2.4
> kernels I've seen so far.
>
> I haven't even tried on 2.2
>
> - Fabio
Fabio,
Just for fun, you might want to try out some of our scheduler patches
"J . A . Magallon" wrote:
> It all depends on your app, as every parallel algorithm. In a web-ftp-whatever
> server, you do not need any synchro. You can start threads in free run and
> let them die alone.
even if you don't need synchronization you pay for it anyway, since you will have
to use
On 03.30 Fabio Riccardi wrote:
>
> Despite of all apparences this method performs beautifully on Linux, pthreads
> are
> actually slower in many cases, since you will incur some additional overhead
> due
> to thread synchronization and scheduling.
>
It all depends on your app, as every
Apache uses a pre-fork "threading" mechanism, it spawns (fork()s) new instances
of itself whenever it finds out that the number of idle "threads" is below a
certain (configurable) threshold.
Despite of all apparences this method performs beautifully on Linux, pthreads are
actually slower in many
; On Thu, 29 Mar 2001, Fabio Riccardi wrote:
>
> > Date: Thu, 29 Mar 2001 13:19:05 -0800
> > From: Fabio Riccardi <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: linux scheduler limitations?
> >
> > Hello,
> >
> > I'm working on
On 03.29 Fabio Riccardi wrote:
>
> I've found a (to me) unexplicable system behaviour when the number of
> Apache forked instances goes somewhere beyond 1050, the machine
> suddently slows down almost top a halt and becomes totally unresponsive,
> until I stop the test (SpecWeb).
>
Have you
2.2 or 2.4 kernel?
the 2.4 does a MUCH better job of dealing with large numbers of processes.
David Lang
On Thu, 29 Mar 2001, Fabio Riccardi wrote:
> Date: Thu, 29 Mar 2001 13:19:05 -0800
> From: Fabio Riccardi <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: linux sch
Hello,
I'm working on an enhanced version of Apache and I'm hitting my head
against something I don't understand.
I've found a (to me) unexplicable system behaviour when the number of
Apache forked instances goes somewhere beyond 1050, the machine
suddently slows down almost top a halt and
Hello,
I'm working on an enhanced version of Apache and I'm hitting my head
against something I don't understand.
I've found a (to me) unexplicable system behaviour when the number of
Apache forked instances goes somewhere beyond 1050, the machine
suddently slows down almost top a halt and
2.2 or 2.4 kernel?
the 2.4 does a MUCH better job of dealing with large numbers of processes.
David Lang
On Thu, 29 Mar 2001, Fabio Riccardi wrote:
Date: Thu, 29 Mar 2001 13:19:05 -0800
From: Fabio Riccardi [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: linux scheduler limitations
On 03.29 Fabio Riccardi wrote:
I've found a (to me) unexplicable system behaviour when the number of
Apache forked instances goes somewhere beyond 1050, the machine
suddently slows down almost top a halt and becomes totally unresponsive,
until I stop the test (SpecWeb).
Have you though
Riccardi wrote:
Date: Thu, 29 Mar 2001 13:19:05 -0800
From: Fabio Riccardi [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: linux scheduler limitations?
Hello,
I'm working on an enhanced version of Apache and I'm hitting my head
against something I don't understand.
I've
Apache uses a pre-fork "threading" mechanism, it spawns (fork()s) new instances
of itself whenever it finds out that the number of idle "threads" is below a
certain (configurable) threshold.
Despite of all apparences this method performs beautifully on Linux, pthreads are
actually slower in many
On 03.30 Fabio Riccardi wrote:
Despite of all apparences this method performs beautifully on Linux, pthreads
are
actually slower in many cases, since you will incur some additional overhead
due
to thread synchronization and scheduling.
It all depends on your app, as every parallel
"J . A . Magallon" wrote:
It all depends on your app, as every parallel algorithm. In a web-ftp-whatever
server, you do not need any synchro. You can start threads in free run and
let them die alone.
even if you don't need synchronization you pay for it anyway, since you will have
to use the
On Thu, Mar 29, 2001 at 01:55:11PM -0800, Fabio Riccardi wrote:
I'm using 2.4.2-ac26, but I've noticed the same behavior with all the 2.4
kernels I've seen so far.
I haven't even tried on 2.2
- Fabio
Fabio,
Just for fun, you might want to try out some of our scheduler patches
located
Hi Mike,
somebody else on the list already pointed me at your stuff and I quickly
downloaded your multiqueue patch for 2.4.1 to try it out.
It works great! I finally manage to have 100% CPU utilization and keep the
machine decently responsive.
On a two 1GHz pentium box i went from 1300 specweb
21 matches
Mail list logo
