From: "Zhao Xiaoming" <xiaoming.nj@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: ZONE_NORMAL memory exhausted by 4000 TCP sockets
Date: Mon, 6 Nov 2006 14:07:02 +0800 [thread overview]
Message-ID: <f55850a70611052207j384e1d3flaf40bb9dd74df7c5@mail.gmail.com> (raw)
Dears,
I'm running a linux box with kernel version 2.6.16. The hardware
has 2 Woodcrest Xeon CPUs (2 cores each) and 4G RAM. The NIC cards is
Intel 82571 on PCI-e bus.
The box is acting as ethernet bridge between 2 Gigabit Ethernets.
By configuring ebtables and iptables, an application is running as TCP
proxy which will intercept all TCP connections requests from the
network and setup another TCP connection to the acture server. The
TCP proxy then relays all traffics in both directions.
The problem is the memory. Since the box must support thousands of
concurrent connections, I know the memory size of ZONE_NORMAL would be
a bottleneck as TCP packets would need many buffers. After setting
upper limit of net.ipv4.tcp_rmem and net.ipv4.tcp_wmem to 32K bytes,
our test began.
My test scenario employs 2000 concurrent downloading connections
to a IIS server's port 80. The throughput is about 500~600 Mbps which
is limited by the capability of the client application. Because all
traffics are from server to client and the capability of client
machine is bottleneck, I believe the receiver side of the sockets
connected with server and the sender side of the sockets connected
with client should be filled with packets in correspondent windows.
Thus, roughly there should be about 32K * 2000+ 32K*2000 = 128M bytes
memory occupied by TCP/IP stack for packet buffering. Data from
slabtop confermed it. it's about 140M bytes memory cost after I start
the traffic. That reasonablly matched with my estimation. However,
/proc/meminfo had a different story. The 'LowFree' dropped from about
710M to 80M. In other words, there's addtional 500M memory in
ZONE_NORMAL allocated by someone other than the slab. Why?
I also made another test that the upper limit of tcp_rmem and
tcp_wmem being set to 64K. After 2000 connections transfering a lot of
data for several seconds, the linux box showed some error messages
such as error allocating memory pages, etc. and became unstable.
My questions are:
1. To calculate memory request of TCP sockets, is there any other
large amount of memory requested besides send and receive buffer?
2. Is there any logics that emploied by TCP/IP stack that will
dynamically allocating memory pages directly instead of from slab?
Thanks!
Xiaoming.
next reply other threads:[~2006-11-06 6:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-06 6:07 Zhao Xiaoming [this message]
2006-11-06 7:34 ` Eric Dumazet
2006-11-06 8:10 ` Zhao Xiaoming
2006-11-06 8:48 ` Eric Dumazet
2006-11-06 9:03 ` Zhao Xiaoming
2006-11-06 8:59 ` Zhao Xiaoming
2006-11-06 9:22 ` Eric Dumazet
2006-11-06 9:46 ` Zhao Xiaoming
2006-11-06 9:49 ` Zhao Xiaoming
2006-11-06 13:33 ` Eric Dumazet
2006-11-07 2:48 ` Zhao Xiaoming
2006-11-07 5:53 ` Eric Dumazet
2006-11-07 6:08 ` Zhao Xiaoming
2006-11-06 16:36 ` Stephen Hemminger
2006-11-07 2:50 ` Zhao Xiaoming
2006-11-07 6:00 ` Zhao Xiaoming
2006-11-06 10:13 ` Arjan van de Ven
2006-11-06 10:21 ` Zhao Xiaoming
2006-11-06 10:21 ` Zhao Xiaoming
2006-11-07 8:06 Al Boldi
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=f55850a70611052207j384e1d3flaf40bb9dd74df7c5@mail.gmail.com \
--to=xiaoming.nj@gmail.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
all inboxes | Powered by JetHome®