* Re: [LARTC] Conntrack table full and Heavy p2p loaded traffic manager
2007-02-23 19:28 [LARTC] Conntrack table full and Heavy p2p loaded traffic manager Sébastien CRAMATTE
2007-02-24 10:37 ` [LARTC] Conntrack table full and Heavy p2p loaded traffic Andrew Beverley
@ 2007-02-25 1:37 ` Luciano Ruete
2007-02-28 1:28 ` Luciano Ruete
2 siblings, 0 replies; 4+ messages in thread
From: Luciano Ruete @ 2007-02-25 1:37 UTC (permalink / raw)
To: lartc
On Friday 23 February 2007 16:28, Sébastien CRAMATTE wrote:
> Hello
>
> I've setuped a bridge with l7-filter and ipp2p. We have every day + or
> - between 10Mbits and 30 Mbits P2P traffic from + or - 450 customers.
> When traffic increase. I've got this kind of error message :
>
> Feb 23 14:26:19 gestor1 kernel: printk: 38 messages suppressed.
> Feb 23 14:26:19 gestor1 kernel: ip_conntrack: table full, dropping packet.
>
> The server is celeron pentium 4 based 3Ghz + 512Mb ram
> Does anyone could suggest me what are the best value for
>
> net.ipv4.netfilter.ip_conntrack_max
> net.ipv4.netfilter.ip_conntrack_tcp_timeout_established
leave the timeouts as is, and focus on the conntrack_max,
lnstat command is your friend, will help to find the magic numbers:
lnstat -f ip_conntrack -i 1 -c 1
this will tell you the number of entries used in real time, so you can put a
very large value in ip_conntrack_max and monitor with lnstat and crontab like
this:
*/5 * * * * root date >> /var/log/conntrack_watchdog.log; lnstat -f
ip_conntrack -i 1 -c 1 >> /var/log/conntrack_watchdog.log
After a couple of days you are ready to put the perfect number for you
personal enviroment.
Each conntrack entrie is about 350bytes from non-swappable kernel memory, so
you can make your maths to know how much RAM is consumed.
> Might be I can tune other kernel value ?
yes, in large setups is recommended to change the conntrack hash table size:
modrobe ip_conntrack hashsize=xxx
to avoid to have a large ammount of entries in the same bucket, this can have
performmance issues, you can check your acctual hash table size looking at
dmesg.
--
Luciano
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [LARTC] Conntrack table full and Heavy p2p loaded traffic manager
2007-02-23 19:28 [LARTC] Conntrack table full and Heavy p2p loaded traffic manager Sébastien CRAMATTE
2007-02-24 10:37 ` [LARTC] Conntrack table full and Heavy p2p loaded traffic Andrew Beverley
2007-02-25 1:37 ` [LARTC] Conntrack table full and Heavy p2p loaded traffic manager Luciano Ruete
@ 2007-02-28 1:28 ` Luciano Ruete
2 siblings, 0 replies; 4+ messages in thread
From: Luciano Ruete @ 2007-02-28 1:28 UTC (permalink / raw)
To: lartc
On Monday 26 February 2007 06:07, you wrote:
> Hello,
cc to the list, it may help others.
> Thanks for your answer
> Do you know a method to choose hashSize as you explain me for
> conntrack max ?
Yes, the hash table size(search wikipedia if you do not know what a hash table
is) is the numbers of bucket that you have.
So if you have a table with 10 buckets and you put 160 conntrack
entries(conntrack_max), then each bucket will have 16 average entries. In
practice can happens that a bucket has 0 and other has 30 or more, it depends
on the eficency of the hash algorithm, but you can assume an average of 16 to
do your maths.
After the bucket is found by the hash function, the entrie is searched
lineary, so in our example with hash_size at 10 and conntrack_max at 160, the
kernel will do at last an 16 items linear search, so just to simplify, whe
can assume an average linear search of 8 items.
In a 1GB memroy i386PC, the linux kernel defaults to 8180 buckets and 65440
entries, if you start reciving messages that conntrack table is full, you can
just rise up the entries to an 1/16 ratio (as in the example above), this
means set conntrack_max to 13088 and leave hash_size in 8180.
At 5000 searches per second you will have an average of 5000*8@000 aditional
operations to search an item, 40000 operations/second shure cost some cpu
cycles.
But if you rise up the bucket as well to 65440(1/2 ratio) you will reduce the
number to just 5000 operations per second.
To choose the rigth number just depends on how much RAM you have, how fast is
you CPU, and how many searches are made in the conntrack table.
--
Luciano
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 4+ messages in thread