On Fri, 20 Jul 2007, Thomas Jacob wrote:
On Thu, Jul 19, 2007 at 05:18:19PM -0700, Konstantin Svist wrote:
alright, so far I have:
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_syncookies = 1
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_no_metrics_save = 1
AFAIK those values do not influence netfilter performance,
just local tcp socket performance.
net.ipv4.netfilter.ip_conntrack_max = 1024000
what would you recommend for the buckets? is default (8192) reasonable?
At the moment I am always setting this to the value of ip_conntrack_max
(on the theory that this should result in constant lookup times), as I
can spare the memory. But I haven't run any real performance tests with
lower hash bucket counts....
you should run the tests. doing a hash across too many buckets ends up costing
performance as well.
you want the list per bucket to not be too long, but you also don't want to
spend more effort and ram on empty buckets.
setting conntrack_max equal to the number of buckets doesn't mean that you will
have one entry in each bucket, it means that you will have a lot of empty
buckets and other buckets with several items in them.
hash algorithms have collisions (cases where different input generates the same
output) cryptographicly strong hashes mean that it's really hard to create a
second input that results in the same output as some other existing input. but
collisions do happen there.
The FAQ says though, that one should use odd hash bucket counts, so you
might want to decrease that by one.
it's not unusual for simple (i.e. cheap to use) has algorithims to have
pathalogical results for specific sizes. ideally you want the bucket count to be
a prime number, if it's not (for example a even power of 2) you can get
situations where it only puts things in a very small number of buckets.
David Lang
