All of
 help / color / mirror / Atom feed
From: Martin Josefsson <>
To: Dax Kelson <>
Subject: Re: Memory usage for ip_conntrack
Date: 18 Jul 2003 23:28:10 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, 2003-07-18 at 22:07, Dax Kelson wrote:
> I'm teaching a Linux class and the book says "Using ip_conntrack will
> use much more memory".
> A student asked me how much is "much".
> So on a 2.4.20+  how much memory does it take to track the state of a
> connection?

This depends on which patches you've applied and if you have selected
NAT support when you compiled it or not. You can see how much memory it
uses by looking at the kernel output when ip_conntrack is initialized.
It looks like:

ip_conntrack version 2.1 (5632 buckets, 45056 max) - 304 bytes per conntrack

That's the number of bytes ip_conntrack will try to allocate for each
connection. But it isn't neccessarily the real number of bytes
allocated. You'll have to look at /proc/slabinfo for that. Look at
column 4, that's the object size. In my case it's 320 bytes.

And each bucket in the hashtable will use 8 bytes on a 32bit machine, 16
bytes on a 64bit machine.

> If I echo 102400 > /proc/sys/net/ipv4/ip_conntrack_max, what is my worst
> case memory usage?

Don't do this. This will increase the maximum number of connections it
will track, but not the number of buckets. Which means that it will be
slower due to longer collision-chains. Instead increase the number of
buckets. modprobe ip_conntrack hashsize=131072 (or any number here. If
it's a < 2.4.21 kernel 2^n sizes aren't recommended due to a poor
hashfunction. Instead you should use 2^n-1)

In my case the memory-usage for the above numbers would be:

5632 buckets * 8 bytes (32bit machine)
102400 * 320 bytes (object size from slabinfo)
= 45056 + 32768000 ~= 31.3 MB

Increasing the number of buckets doesn't cost much memory compared to
the actual connections and it gives you a nice performanceboost if you
are trying to handle lots of connections. (the default is based on the
amount of memory in the machine and it's normally ok for desktop
machines and small servers/routers)

ip_conntrack is a memory-hog, we are working on reducing the


  reply	other threads:[~2003-07-18 21:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-18 20:07 Memory usage for ip_conntrack Dax Kelson
2003-07-18 21:28 ` Martin Josefsson [this message]
2003-07-19  0:12   ` Memory usage/tuning " Dax Kelson
2003-07-20  0:10   ` Memory usage " Carlos Carvalho
2003-07-24 16:01     ` Harald Welte

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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.