|
Hi!
Together with Roberto Nibali <ratz> I found the main reasons for
the slow redirector. DMA wasn't activated. Then, those $#%@! who
installed the kernel on the other machine used an old version
of the driver with a new kernel ("downpatching" :)
O.K. FTP'ing a 300MB file takes 29sec now - 10 MByte per second,
80 MBps on a 100 MBps line. Is the still problem or is the missing
20% normal? (Cards on autodetect/negotiate)
rp_filter=1 didn't do much in the ftp scenario, but you can't tell
for sure, because it's always changing a bit - maybe 5%.
BUT:
When simulating 1 client (director has no work), up to 52,000 packets
per second arrive on the cache. This decreases with the increasing
number of simulated clients.
When simulating around 100,000 clients, the director starts not
to serve in real time: ipvsadm shows only 99,934 inactive conns.
When simulating 150,000 clients, we get errors because he can't
allocate memory - we have 256MB I guess. But nevertheless, the
load shown by top is about 400%
> Yes, it seems there is one trick here. If you enable the rp_filter
> for the indev in the real server the packets with saddr from the rejected
> network are treated as source martians. But with rp_filter=0 route -Cn
> shows that an incoming route is created in the routing cache, so it seems
> this packet reaches the inqueue. This can be a good reason the syn backlog
> to overflow. So, the recommendations is: don't enable the SYN cookies in
> this test, of course, if you don't want to test the SYN cookies support.
> And rp_filter=1 can help to drop the packets faster. Then you don't need
> to alter any tcp settings.
I'll have to do those settings and do further tests with testLVS.
Regards
Thomas
--
If a train station is where the train stops, what's a workstation?
|
