public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christian Schmid <webmaster@rapidforum.com>
To: linux-kernel@vger.kernel.org
Subject: BUG: Slowdown on 3000 socket-machines tracked down
Date: Sat, 05 Mar 2005 18:10:29 +0100	[thread overview]
Message-ID: <4229E805.3050105@rapidforum.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]

Hello.

After weeks of work, I can now give a detailed report about the bug and when it appears:

Attached is another traffic-image. This one is with 2.6.10 and a 3/1 split, preemtive kernel, so all 
defaults.

The first part is where I throttled the whole thing to 100 MBit in order to build up a traffic-jam ;)

When I released it, it jumped up immediately but suddenly it goes down (each pixel is one second) 
Playing around with min_free_kbytes didnt help. Where it goes up again I set lower_zone_protection 
to 1024000 and where it goes down I set it to 0 again and where it goes up the last time... guess..

This test was with 3500 sockets.

Today I tested with 5000 sockets. The problem is the same like above but the more sockets there 
come, it just doesnt claim more bandwidth as it SHOULD of course do. It seems it doesn't slow down 
but it just doesnt scale anymore. The badwidth doesnt go over 80 MB/Sec, no matter what I do. Then I 
did the following: I raised lower_zone_protection to 1024 (above I did 1024000 which is bullshit but 
it doesnt matter as it seems to just protect the whole low-mem which is what I want) and it was at 
80 MB. then I lowered to 0 again and suddenly it peaked up to full bandwidth (100 MB) for about 5 
seconds until the whole protected area was in use. Then it slowed down drastically again.

My theory:

I suppose when the blocks come in fast enough and the load is high enough, the kernel cant free the 
required low memory as fast as this would be required in order to NOT slow-down everything. So the 
vm is basically busy freeing low-memory. What do you think? The interesting part is that it slows 
down painfully with lower_zone_protection set to 0, it peaks at 80 MB/Sec with lower_zone_protection 
set to max (1024, whole low-mem) and there is much cpu-ressources free..... When set to 0 it speeds 
up without limit AS LONG AS there is memory left. When its consumed, it slows down painfully again 
because its set to 0 of course.

Chris

[-- Attachment #2: traffic2.png --]
[-- Type: image/png, Size: 2504 bytes --]

             reply	other threads:[~2005-03-05 17:20 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-05 17:10 Christian Schmid [this message]
2005-03-07  0:45 ` BUG: Slowdown on 3000 socket-machines tracked down 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
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=4229E805.3050105@rapidforum.com \
    --to=webmaster@rapidforum.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