From: Filip Sneppe <filip.sneppe@cronos.be>
To: "Cilliè Burger" <security@sadomain.co.za>
Cc: netfilter@lists.netfilter.org
Subject: Re: Memory problem
Date: 03 Jul 2003 16:42:04 +0200 [thread overview]
Message-ID: <1057243325.458.166.camel@xbox> (raw)
In-Reply-To: <3F044612.8020903@sadomain.co.za>
Hi Cilliè,
On Thu, 2003-07-03 at 17:04, Cilliè Burger wrote:
> Here are the details you requested.
>
> cat /proc/meminfo
> total: used: free: shared: buffers: cached:
> Mem: 63598592 62529536 1069056 0 23306240 19935232
> Swap: 200237056 3911680 196325376
> MemTotal: 62108 kB
> MemFree: 1044 kB
> MemShared: 0 kB
> Buffers: 22760 kB
> Cached: 19192 kB
> SwapCached: 276 kB
> Active: 26476 kB
> Inact_dirty: 14428 kB
> Inact_clean: 2428 kB
> Inact_target: 8664 kB
> HighTotal: 0 kB
> HighFree: 0 kB
> LowTotal: 62108 kB
> LowFree: 1044 kB
> SwapTotal: 195544 kB
> SwapFree: 191724 kB
> Committed_AS: 6052 kB
>
> ------------------------------------------------------------
>
>
> cat /proc/slabinfo
> slabinfo - version: 1.1
> kmem_cache 61 70 112 2 2 1
> ip_conntrack 1193 1628 352 127 148 1
...
> inode_cache 17328 19976 496 2497 2497 1
> dentry_cache 17522 23275 112 665 665 1
...
> buffer_head 9797 12040 96 272 301 1
...
>
> wc -l /proc/net/ip_conntrack
> 1107 /proc/net/ip_conntrack
>
See, ip_conntrack is only using 1193 * 352 bytes per connection,
and the number of connections tracked is quite reasonable.
You can also see that a fair amount of RAM is simply used
for caching of filesytem operations (see cached: entry
of meminfo output and the inode_cache and dentry_cache
in slabinfo output).
So I wouldn't worry about any memory leaks in netfilter
connection tracking. The numbers you provided look quite normal.
Regards,
Filip
next prev parent reply other threads:[~2003-07-03 14:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-03 9:53 Memory problem Cilliè Burger
2003-07-03 9:15 ` Filip Sneppe
[not found] ` <3F044612.8020903@sadomain.co.za>
2003-07-03 14:42 ` Filip Sneppe [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-04-24 14:40 Froggy / Froggy Corp.
2005-04-27 13:18 ` Erik Mouw
2005-04-27 16:29 ` Froggy / Froggy Corp.
2004-12-14 20:25 MEMORY PROBLEM ppclinux
2004-12-14 21:07 ` Jerry Van Baren
2004-12-15 16:51 ` ppclinux
2004-09-13 11:11 (unknown) Ankit Jain
2004-09-13 11:51 ` memory problem Ron Michael Khu
2004-05-26 10:14 Memory problem Pankaj
2003-07-03 16:10 Daniel Chemko
2003-04-03 0:40 memory problem 최영일
2002-10-07 14:33 Memory Problem Philipp Steinkrueger
2002-10-07 14:33 ` Philipp Steinkrueger
2002-10-07 15:21 ` Rik van Riel
2002-10-07 15:21 ` Rik van Riel
2002-10-07 15:52 ` Dave Hansen
2002-10-07 17:10 ` Glynn Clements
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=1057243325.458.166.camel@xbox \
--to=filip.sneppe@cronos.be \
--cc=netfilter@lists.netfilter.org \
--cc=security@sadomain.co.za \
/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 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.