From: Ben Greear <greearb@candelatech.com>
To: Christian Schmid <webmaster@rapidforum.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: BUG: Slowdown on 3000 socket-machines tracked down
Date: Sun, 06 Mar 2005 18:57:07 -0800 [thread overview]
Message-ID: <422BC303.9060907@candelatech.com> (raw)
In-Reply-To: <422BB548.1020906@rapidforum.com>
Christian Schmid wrote:
> Ben Greear wrote:
>
>> I have a tool that can also generate TCP traffic on a large number of
>> sockets. If I can understand what you are trying to do, I may be able
>> to reproduce the problem. My biggest machine at present has only
>> 2GB of RAM, however...not sure if that matters or not.
>
> It should not matter. Low-memory is both just 1 GB if you have default
> 32 bit with 3/1 split.
>
>> Are you sending traffic in only one direction, or more of a full-duplex
>> configuration?
>
> Its a full-duplex. Its a download-service with 3000 downloaders all over
> the world.
So actually it's really mostly one-way traffic, ie in the download direction.
Anything significant at all going upstream, other than ACKs, etc?
>> Is each socket running the same bandwidth?
>
> No. It ranges from 3 kb/sec to 100 kb/sec. 100 kb/sec is the limit
> because of the send-buffer limits.
>
>> What is this bandwidth?
>
> 1000 MBit
>
>> Are you setting the send & rcv buffers in the socket creation
>> code? (To what values if so?)
>
> Yes. send-buffer to 64 kbytes and receive buffer to 16 kbytes.
With regard to this note in the 'man 7 socket' man page:
NOTES
Linux assumes that half of the send/receive buffer is used for internal kernel struc-
tures; thus the sysctls are twice what can be observed on the wire.
What value are you using for the sockopt call?
>> How many bytes are you sending with each call to write()/sendto()
>> whatever?
>
> I am using sendfile-call every 100 ms per socket with the poll-api. So
> basically around 40 kb per round.
My application is single-threaded, uses non-blocking IO, and sends/rcvs from/to memory.
It will be a good test of the TCP stack, but will not use the sendfile logic,
nor will it touch the HD.
>> Is there any significant latency between your sender and receiver
>> machine?
>> If so, how much?
>
> 3000 different downloaders, 3000 different locations, 3000 different
> machines ;)
I can emulate delay if I need to, but I'd rather just stick with one
delay setting and not have to set up a separate delay for each connection.
Maybe 30ms is average for round-trip time?
Have you tried benchmarking your app in a controlled manner, or are you just
letting a random 3000 machines hit it and start downloading? If the latter,
then I'd suggest getting more controll over your testing environment, otherwise
it may be impossible to really figure out where the problem lies.
I'll set up a configuration similar to the values discussed above and see
what I can see. Will probably be late tomorrow before I can do the
test though...
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2005-03-07 2:57 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 [this message]
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=422BC303.9060907@candelatech.com \
--to=greearb@candelatech.com \
--cc=linux-kernel@vger.kernel.org \
--cc=webmaster@rapidforum.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