mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Zhao Xiaoming" <xiaoming.nj@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: Re: ZONE_NORMAL memory exhausted by 4000 TCP sockets
Date: Mon, 6 Nov 2006 16:10:03 +0800	[thread overview]
Message-ID: <f55850a70611060010q3ce9d6d2h4026259d688c6db1@mail.gmail.com> (raw)
In-Reply-To: <454EE580.5040506@cosmosbay.com>

2006/11/6, Eric Dumazet <dada1@cosmosbay.com>:
> Zhao Xiaoming a écrit :
> > 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?
>
> We dont know. You might post some data so that we can have some ideas.
>
> Also, these kind of question is better handled by linux netdev mailing list,
> so I added a CC to this list.
>
> cat /proc/slabinfo
> cat /proc/meminfo
> cat /proc/net/sockstat
> cat /proc/buddyinfo
>
> >   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?
>
> TCP stack is one thing, but other things may consume ram on your kernel.
>
> Also, kernel memory allocation might use twice the ram you intend to use
> because of power of two alignments.
>
> Are you using iptables connection tracking ?
>
> If you plan to use a lot of RAM in kernel, why dont you use a 64 bits kernel,
> so that all ram is available for kernel, not only 900 MB ?
>
> Eric
>
>
Thanks for the answer. I know it's more likely relats to netdev.
However, it's always a strange thing to have 400~500M bytes LOWMEM
'gone' while it's not reported to be occupied by slab. Both meminfo
and buddyinfo tell the same.

with traffics of 2000 concurrent sessions:

cat /proc/meminfo
MemTotal:      4136580 kB
MemFree:       3298460 kB
Buffers:          4096 kB
Cached:          21124 kB
SwapCached:          0 kB
Active:          47416 kB
Inactive:        12532 kB
HighTotal:     3276160 kB
HighFree:      3214592 kB
LowTotal:       860420 kB
LowFree:         83868 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:              12 kB
Writeback:           0 kB
Mapped:          42104 kB
Slab:           293952 kB
CommitLimit:   2068288 kB
Committed_AS:    58892 kB
PageTables:       1112 kB
VmallocTotal:   116728 kB
VmallocUsed:      2940 kB
VmallocChunk:   110548 kB
HugePages_Total:     0
HugePages_Free:      0
Hugepagesize:     2048 kB


without traffics:

cat /proc/meminfo
MemTotal:      4136580 kB
MemFree:       3924276 kB
Buffers:          4460 kB
Cached:          21020 kB
SwapCached:          0 kB
Active:          47592 kB
Inactive:        12848 kB
HighTotal:     3276160 kB
HighFree:      3214716 kB
LowTotal:       860420 kB
LowFree:        709560 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:              40 kB
Writeback:           0 kB
Mapped:          42368 kB
Slab:           132172 kB
CommitLimit:   2068288 kB
Committed_AS:    59220 kB
PageTables:       1140 kB
VmallocTotal:   116728 kB
VmallocUsed:      2940 kB
VmallocChunk:   110548 kB
HugePages_Total:     0
HugePages_Free:      0
Hugepagesize:     2048 kB


Xiaoming.

  reply	other threads:[~2006-11-06  8:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-06  6:07 Zhao Xiaoming
2006-11-06  7:34 ` Eric Dumazet
2006-11-06  8:10   ` Zhao Xiaoming [this message]
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=f55850a70611060010q3ce9d6d2h4026259d688c6db1@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®