|
Hello,
On Mon, 17 Dec 2001, Fabrice wrote:
> Hello,
>
> I had a similar problem when I ran testlvs, with conntrack enabled
> on the client machine (the one that runs testlvs), I had a mean of
> about 2000 SYN/s. When I removed thoses modules (there are
> many conntracks) I reached 54'000 SYN/s!
>
> This is only one particular case where conntrack seems to slowdown
> the connection rate, it may or may not have some consequence for
> a LVS box. I'm curious to hear about the tests that Julian is going
> to do :)
I performed some tests, may be I'll not be able to do more
this year.
The test: 40K SYN/s Incoming (director near its limits),
LVS-NAT, 2.4.16, noapic, SYN flood from testlvs with -srcnum 32000
to 1 RS. May be not very accurate (make the tests yourself :)).
- only IPVS 0.9.8
- able to send the 40K/sec (same as incoming)
- 3000 context switches/sec
- after modprobe ip_conntrack hashsize=131072
- 10-15% performance drop
- 500 context switches/sec
- after modprobe iptable_nat (no NAT rules):
- 5% performance drop
- same number of context switches/sec
Additional test: -j DNAT instead of IPVS,
# modprobe ip_conntrack hashsize=131072
# modprobe iptable_nat
# cat /proc/sys/net/ipv4/ip_conntrack_max
1048576
Tragedy: 1000P/s out, director is overloaded.
I looked into the ip_conntrack hashing, it is not perfect
for incoming traffic between two IPs but note that testlvs uses
different IPs, so after little tuning, it seems that the DNAT's
problem is not the bad hash function. There is something else ...
No time to investigate today. May be I'm missing some NF tuning
parameters.
> Fabrice Bucher
Regards
--
Julian Anastasov <ja@xxxxxx>
|
