From: Sean Hunter <sean@dev.sportingbet.com>
To: matthew <matthew@mattshouse.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.4.0-test10 Sluggish After Load
Date: Wed, 1 Nov 2000 17:13:21 +0000 [thread overview]
Message-ID: <20001101171321.A8815@bart.dev.sportingbet.com> (raw)
In-Reply-To: <20001101152629.B31394@bart.dev.sportingbet.com> <Pine.LNX.4.21.0011011107170.7127-100000@localhost.localdomain>
In-Reply-To: <Pine.LNX.4.21.0011011107170.7127-100000@localhost.localdomain>; from matthew@mattshouse.com on Wed, Nov 01, 2000 at 11:10:46AM -0600
On Wed, Nov 01, 2000 at 11:10:46AM -0600, matthew wrote:
> On Wed, 1 Nov 2000, Sean Hunter wrote:
>
> > Pardon my speculations (if I am wrong), but isn't this an oracle question?
>
>
> It could be.
>
>
> > Isn't oracle killing the server by trying to clean up 1800 connections all at
> > once? When they're all connected, most of the work is done by one or two
> > oracle processes, but when you kill your ddos thing, all of the oracle
> > listeners (of which there is one per connection), steam in and try to clean up.
>
>
> Yes, but the factor that drove me to the list was that it's been > 400
> load average for 10 hours now. Even if Oracle tried to clean up 1800
> connections at once, would it take this long? That's not rhetorical, as
> the answer may well be "yes".
>
Yup. What seems to have happened is that waking up 1800 processes at once has
caused the box to thrash so hard it is taking ages for any one process to get
enough scheduler time to clean itself up and exit.
I guess we may need a thrash preventer that slows things down enough for each
process to get a healthy bite of the cherry.
Sean
>
> > I thought oracle had an internal connection limit (on our servers it is set to
> > 440 connections), anyways.
>
>
> This is set in the init.ora. I jacked it up to allow > 2000 connections.
>
> Matthew
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-11-01 17:20 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-01 15:00 2.4.0-test10 Sluggish After Load matthew
2000-11-01 15:26 ` Sean Hunter
2000-11-01 17:10 ` matthew
2000-11-01 17:13 ` Sean Hunter [this message]
2000-11-01 17:29 ` Rik van Riel
2000-11-02 11:09 ` Alessandro Suardi
-- strict thread matches above, loose matches on Subject: below --
2000-11-01 15:44 Jonathan George
2000-11-01 16:05 ` Rik van Riel
2000-11-03 12:54 ` Christoph Rohland
2000-11-04 13:05 ` Rik van Riel
2000-11-04 20:04 ` Christoph Rohland
2000-11-05 13:36 ` Rik van Riel
2000-11-05 18:49 ` Christoph Rohland
2000-11-01 16:18 Jonathan George
2000-11-01 16:56 ` Rik van Riel
2000-11-02 8:48 ` Christoph Rohland
2000-11-02 13:52 ` Rik van Riel
2000-11-02 16:22 ` matthew
2000-11-04 1:31 ` Peter Samuelson
2000-11-01 16:59 ` matthew
2000-11-01 17:11 ` Rik van Riel
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=20001101171321.A8815@bart.dev.sportingbet.com \
--to=sean@dev.sportingbet.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@mattshouse.com \
/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