From: Fabio Riccardi <fabio@chromium.com>
To: David Lang <dlang@diginsite.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: linux scheduler limitations?
Date: Thu, 29 Mar 2001 13:55:11 -0800 [thread overview]
Message-ID: <3AC3AF3E.F083EE36@chromium.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0103291326110.26411-100000@dlang.diginsite.com>
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
David Lang wrote:
> 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 <fabio@chromium.com>
> > To: linux-kernel@vger.kernel.org
> > 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 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).
> >
> > Profiling the kernel shows that the scheduler and the interrupt handler
> > are taking most of the CPU time.
> >
> > I understand that there must be a limit to the number of processes that
> > the scheduler can efficiently handle, but I would expect some sort of
> > gradual performance degradation when increasing the number of tasks,
> > instead I observe that by increasing Apache's MaxClient linit by as
> > little as 10 can cause a sudden transition between smooth working with
> > lots (30-40%) of CPU idle to a total lock-up.
> >
> > Moreover the max number of processes is not even constant. If I increase
> > the server load gradually then I manage to have 1500 processes running
> > with no problem, but if the transition is sharp (the SpecWeb case) than
> > I end-up having a lock up.
> >
> > Anybody seen this before? Any clues?
> >
> > - Fabio
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
next prev parent reply other threads:[~2001-03-29 21:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-29 21:19 linux scheduler limitations? Fabio Riccardi
2001-03-29 21:26 ` David Lang
2001-03-29 21:55 ` Fabio Riccardi [this message]
2001-03-30 1:45 ` Mike Kravetz
2001-03-30 2:58 ` Fabio Riccardi
2001-03-29 21:35 ` J . A . Magallon
2001-03-29 22:12 ` Fabio Riccardi
2001-03-29 22:33 ` J . A . Magallon
2001-03-29 22:51 ` Fabio Riccardi
2001-03-30 6:52 ` Giuliano Pochini
2001-04-02 22:58 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3AC3AF3E.F083EE36@chromium.com \
--to=fabio@chromium.com \
--cc=dlang@diginsite.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox