ME TOO: ip_conntrack / available memory = cRaSh

[Raj]

Thanks for the info, Felipe. But I see that I should have had tons of
free memory left as 8192 conns x 350 bytes = 2867200 bytes (~3 MB) right!

How come the FAQ 3.6 on the netfilter site states, I mean how has the
calculation been done?
...64MB: 4096, 128MB: 8192...at 350 bytes/tracked connections!

Whereas when the system starts dropping packets most of my non-swappable
mem is used up and this happens ~4/5 days after the last reboot.
I have now increased my physical mem to 256 MB from 128 MB. After the
upgrade I noticed that the ip_conntrackmax was automatically increased to
16312 and I manually reduced it to 8192 though.

Right now, the stats are as follows after 2 days since last reboot:

#grep conntrack /proc/slabinfo
ip_conntrack        5012   5700    384  550  570    1

#cat /proc/net/ip_conntrack | wc -l
   4672

Could anyone please enlighten me on the relation between the above two
results. Are they related in any way?

#procinfo
Memory:      Total        Used        Free      Shared     Buffers   Cached
Mem:        254468       46664      207804           0       14824   12192
Swap:       240932           0      240932

I feel that my ip_conntrack database is showing a lot more than my actual
connections as I do not think there exists so many connections even at
peak times (traffic is 1.5 Mbps). OR maybe it is keeping the connection
info for too long...stale info not expiring.
Is there a way to set the expire time?

Or I am getting DOSed all the time :) which I don't think is possible.

So, what may have been the cause for consuming so much memory that
resulted in serious packet drops?

I would like to know how much mem do the systems that handle >10,000
connections with >50 mbps traffic...like our friend Juri Haberland.
What are your ip_conntrack_max settings and readings?

Thanks...

Raj

On Fri, 30 Nov 2001, Felipe Gustavo de Almeida wrote:

> Mailing list writes:
> > [...]
> > I noticed that the physical memory was used up completely when the packet
> > loss occurs and no swap used at all.
> As noted in netfilter FAQ, section item 3.6
> (http://netfilter.samba.org/netfilter-faq-3.html)
> "... each tracked connection eats about 350 bytes of non-swappable kernel
> memory!"
>
> note the 'NON-SWAPPABLE'
> >
> > I have gone thru the archive and found out many issues regarding the
> > ip_conntrack limit and the performance.
> >
> > The box serves very well at other times.
> > Could any iptables guru enlighten me as to what can be done to solve this
> > VERY critical problem of mine.
> >
> > Thanks in advance,
> >
> > Raj
> >
> > Current system info:
> > ----------------------------------------------
> > cat /proc/sys/net/ipv4/ip_conntrack_max : 8192
> >
> > grep conntrack /proc/slabinfo :
> > ip_conntrack        3777   4110    384  400  411    1
> >
> > top :
> > CPU states:  0.1% user,  2.1% system,  0.0% nice, 97.6% idle
> > Mem:   125580K av,   75160K used,   50420K free,       0K shrd,   23200K
> > buff
> > Swap:  240932K av,       0K used,  240932K free                   13884K
> > cached
>
>