All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alessandro Suardi <alessandro.suardi@oracle.com>
To: Sean Hunter <sean@dev.sportingbet.com>
Cc: matthew <matthew@mattshouse.com>, linux-kernel@vger.kernel.org
Subject: Re: 2.4.0-test10 Sluggish After Load
Date: Thu, 02 Nov 2000 12:09:06 +0100	[thread overview]
Message-ID: <3A014B52.D4F5AD53@oracle.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0011010845210.6574-100000@localhost.localdomain> <20001101152629.B31394@bart.dev.sportingbet.com>

Sean Hunter wrote:
> 
> Pardon my speculations (if I am wrong), but isn't this an oracle question?

Maybe, maybe not... what Oracle version ?

> 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.

PMON does the cleanup, so you may have 1 process pegging your CPU at 100%,
 which is not what you see. How does your stress tester work exactly and
 what happens when you stop it ? (my guess is that shadow processes may
 have gone into a CPU loop if detached from the calling process and yes
 that would be abnormal behavior on Oracle's side).

> I thought oracle had an internal connection limit (on our servers it is set to
> 440 connections), anyways.

If Oracle couldn't manage 1800 connections that would be bad news :)


Thanks & ciao,

--alessandro      <alessandro.suardi@oracle.com> <asuardi@uninetcom.it>

Linux:  kernel 2.2.18p18/2.4.0-t10p7 glibc-2.1.94 gcc-2.95.2 binutils-2.10.0.33
Oracle: Oracle8i 8.1.6.1.0 Enterprise Edition for Linux
motto:  Tell the truth, there's less to remember.
-
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/

  parent reply	other threads:[~2000-11-02 11:09 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
2000-11-01 17:29       ` Rik van Riel
2000-11-02 11:09   ` Alessandro Suardi [this message]
  -- 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=3A014B52.D4F5AD53@oracle.com \
    --to=alessandro.suardi@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew@mattshouse.com \
    --cc=sean@dev.sportingbet.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.