From: Russell King <hidden> Date: 2005-01-27 08:28:28
On Tue, Jan 25, 2005 at 07:32:07PM +0000, Russell King wrote:
On Mon, Jan 24, 2005 at 11:48:53AM +0000, Russell King wrote:
quoted
On Sun, Jan 23, 2005 at 08:03:15PM +0000, Russell King wrote:
quoted
I think I may be seeing something odd here, maybe a possible memory leak.
The only problem I have is wondering whether I'm actually comparing like
with like. Maybe some networking people can provide a hint?
Below is gathered from 2.6.11-rc1.
bash-2.05a# cat /proc/net/rt_cache | wc -l; grep ip_dst /proc/slabinfo
24
ip_dst_cache 669 885 256 15 1
I'm fairly positive when I rebooted the machine a couple of days ago,
ip_dst_cache was significantly smaller for the same number of lines in
/proc/net/rt_cache.
FYI, today it looks like this:
bash-2.05a# cat /proc/net/rt_cache | wc -l; grep ip_dst /proc/slabinfo
26
ip_dst_cache 820 1065 256 15 1
So the dst cache seems to have grown by 151 in 16 hours... I'll continue
monitoring and providing updates.
Tonights update:
50
ip_dst_cache 1024 1245 256 15 1
As you can see, the dst cache is consistently growing by about 200
entries per day. Given this, I predict that the box will fall over
due to "dst cache overflow" in roughly 35 days.
This mornings magic numbers are:
3
ip_dst_cache 1292 1485 256 15 1
Is no one interested in the fact that the DST cache is leaking and
eventually takes out machines? I've had virtually zero interest in
this problem so far.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
I just did a q-n-d test here: send one UDP frame to 1.1.1.1 up to
1.1.255.255. The ip_dst_cache grew to ~15k entries and grew no further.
It's now gradually shrinking. So there doesn't appear to be a trivial
bug..
Is no one interested in the fact that the DST cache is leaking and
eventually takes out machines? I've had virtually zero interest in
this problem so far.
I guess we should find a way to make it happen faster.
I just did a q-n-d test here: send one UDP frame to 1.1.1.1 up to
1.1.255.255. The ip_dst_cache grew to ~15k entries and grew no further.
It's now gradually shrinking. So there doesn't appear to be a trivial
bug..
quoted
Is no one interested in the fact that the DST cache is leaking and
eventually takes out machines? I've had virtually zero interest in
this problem so far.
I guess we should find a way to make it happen faster.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Data point... on my box, used as ed2k/bittorrent
machine, the ip_dst_cache grows and shrinks quite
fast; these two samples were ~3 minutes apart:
[root@donkey ~]# grep ip_dst /proc/slabinfo
ip_dst_cache 998 1005 256 15 1 : tunables 120 60
0 : slabdata 67 67 0
[root@donkey ~]# wc -l /proc/net/rt_cache
926 /proc/net/rt_cache
[root@donkey ~]# grep ip_dst /proc/slabinfo
ip_dst_cache 466 795 256 15 1 : tunables 120 60
0 : slabdata 53 53 0
[root@donkey ~]# wc -l /proc/net/rt_cache
443 /proc/net/rt_cache
and these were 2 seconds apart
[root@donkey ~]# wc -l /proc/net/rt_cache
737 /proc/net/rt_cache
[root@donkey ~]# grep ip_dst /proc/slabinfo
ip_dst_cache 795 795 256 15 1 : tunables 120 60
0 : slabdata 53 53 0
[root@donkey ~]# wc -l /proc/net/rt_cache
1023 /proc/net/rt_cache
[root@donkey ~]# grep ip_dst /proc/slabinfo
ip_dst_cache 1035 1035 256 15 1 : tunables 120 60
0 : slabdata 69 69 0
--alessandro
"And every dream, every, is just a dream after all"
(Heather Nova, "Paper Cup")
I just did a q-n-d test here: send one UDP frame to 1.1.1.1 up to
1.1.255.255. The ip_dst_cache grew to ~15k entries and grew no further.
It's now gradually shrinking. So there doesn't appear to be a trivial
bug..
quoted
Is no one interested in the fact that the DST cache is leaking and
eventually takes out machines? I've had virtually zero interest in
this problem so far.
I guess we should find a way to make it happen faster.
I could be a refcount problem. I think Russell is using NAT, it could be
the MASQUERADE target if that is in use. A simple test would be to switch
to SNAT and try again if possible.
/Martin
From: Robert Olsson <hidden> Date: 2005-01-27 13:00:13
Andrew Morton writes:
> Russell King [off-list ref] wrote:
> > ip_dst_cache 1292 1485 256 15 1
> I guess we should find a way to make it happen faster.
Here is route DoS attack. Pure routing no NAT no filter.
Start
=====
ip_dst_cache 5 30 256 15 1 : tunables 120 60 8 : slabdata 2 2 0
After DoS
=========
ip_dst_cache 66045 76125 256 15 1 : tunables 120 60 8 : slabdata 5075 5075 480
After some GC runs.
==================
ip_dst_cache 2 15 256 15 1 : tunables 120 60 8 : slabdata 1 1 0
No problems here. I saw Martin talked about NAT...
--ro
From: Robert Olsson <hidden> Date: 2005-01-27 13:04:24
Oh. Linux version 2.6.11-rc2 was used.
Robert Olsson writes:
>
> Andrew Morton writes:
> > Russell King [off-list ref] wrote:
>
> > > ip_dst_cache 1292 1485 256 15 1
>
> > I guess we should find a way to make it happen faster.
>
> Here is route DoS attack. Pure routing no NAT no filter.
>
> Start
> =====
> ip_dst_cache 5 30 256 15 1 : tunables 120 60 8 : slabdata 2 2 0
>
> After DoS
> =========
> ip_dst_cache 66045 76125 256 15 1 : tunables 120 60 8 : slabdata 5075 5075 480
>
> After some GC runs.
> ==================
> ip_dst_cache 2 15 256 15 1 : tunables 120 60 8 : slabdata 1 1 0
>
> No problems here. I saw Martin talked about NAT...
>
> --ro