All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Schmid <webmaster@rapidforum.com>
To: Ben Greear <greearb@candelatech.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>, linux-kernel@vger.kernel.org
Subject: Re: BUG: Slowdown on 3000 socket-machines tracked down
Date: Tue, 08 Mar 2005 17:41:07 +0100	[thread overview]
Message-ID: <422DD5A3.7060202@rapidforum.com> (raw)
In-Reply-To: <422D468C.7060900@candelatech.com>

> Initial test setup:  two machines, running connections between them.
> Mostly asymetric (about 50Mbps in one direction,
> GigE in the other).  Each connection is trying some random rate between 
> 128kbps
> and 3Mbps in one direction, and 1kbps in the other direction.
> 
> Sending machine is dual 3.0Ghz xeons, 1MB cache, HT, and emt64 (running 
> 32-bit
> kernel & user space though). 1GB of RAM
> 
> Receiving machine is dual 2.8Ghz xeons, 512 MB cache, HT, 32-bit.  2GB 
> of RAM
> (but only 850Mbps of low memory of course...saw the thing OOM kill me 
> with 1GB of
> free high memory :( )
> 
> 
> Zero latency:
> 
> 2000 TCP connections:  When I first start, I see errors indicating I'm 
> out of low
>         memory..but it quickly recovers.  Probably because my program 
> takes a small
>         bit of time before it starts reading the sockets.
>         986Mbps of ethernet traffic (counting all ethernet headers)
> 
> 3000 TCP connections:  Same memory issue
>         986Mbps of ethernet traffic, about 82kpps
> 
> 4000 TCP connections:  Had to drop max_backlog to 5000 from 10000 to keep
>         the machine from going OOM and killing my traffic generator (on
>         the receiving side).
>     986Mbps of ethernet traffic
> 
> I will work on some numbers with latency tomorrow (had to stop and
> re-write some of my code to better handle managing the 8000 endpoints
> that 4000 connections requires!)
> 
> I think we can assume that the problem is either related to latency,
> or sendfile, since 4000 connections with no latency rocks along just
> fine...

Hmmmm.... can you try to following just to exclude some theories:

Run it with 4000 sockets and then do the following on the server-machine:

dd if=/dev/zero of=file1 bs=1M count=1024
dd if=/dev/zero of=file2 bs=1M count=1024
dd if=/dev/zero of=file3 bs=1M count=1024
cat file1 > /dev/zero & cat file2 > /dev/zero & cat file3 > /dev/zero &

I THINK it might have something to do with caching-pressure or so. See if there is a slow-down on 
the sending if the page-cache gets full and has to be cleared again.

You are running 2.6.11?

Chris

  reply	other threads:[~2005-03-08 16:41 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-05 17:10 BUG: Slowdown on 3000 socket-machines tracked down Christian Schmid
2005-03-07  0:45 ` Nick Piggin
2005-03-07  1:13 ` Ben Greear
2005-03-07  1:58   ` Christian Schmid
2005-03-07  2:57     ` Ben Greear
2005-03-07  5:14       ` Nick Piggin
2005-03-07  5:30         ` Willy Tarreau
2005-03-07  5:41           ` Nick Piggin
2005-03-07  5:42             ` Nick Piggin
2005-03-07  5:46               ` Willy Tarreau
2005-03-07  9:22         ` Ben Greear
2005-03-07  9:28           ` Nick Piggin
2005-03-08  6:30             ` Ben Greear
2005-03-08 16:41               ` Christian Schmid [this message]
2005-03-09 23:45                 ` Ben Greear
2005-03-09 23:52                   ` Christian Schmid
2005-03-10  0:18                     ` Ben Greear
2005-03-10  0:24                       ` Christian Schmid
2005-03-10  5:17                         ` Andrew Morton
2005-03-10  9:00                           ` Andi Kleen
2005-03-10  9:09                             ` Andrew Morton
2005-03-10  9:12                               ` Andi Kleen
2005-03-10  9:38                                 ` Andrew Morton
2005-03-10 19:03                             ` Ben Greear
2005-03-10 18:51                           ` Christian Schmid
2005-03-10 19:06                           ` Christian Schmid
2005-03-11 15:29                           ` Christian Schmid
2005-03-11 19:10                             ` Ben Greear
2005-03-11 19:27                               ` Christian Schmid
2005-03-14  4:40                                 ` Nick Piggin
2005-03-14  4:53                                   ` Christian Schmid
2005-03-14  5:04                                     ` Nick Piggin
2005-05-28  3:17                                       ` Christian Schmid
2005-06-08  2:26                                       ` Christian Schmid
2005-06-08  2:39                                         ` Nick Piggin
2005-06-08  2:44                                         ` Andrew Morton
2005-03-07 14:35       ` Christian Schmid
2005-03-07 23:37         ` Ben Greear
2005-03-07  2:07   ` Christian Schmid

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=422DD5A3.7060202@rapidforum.com \
    --to=webmaster@rapidforum.com \
    --cc=greearb@candelatech.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    /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.