|
Hello,
On Fri, 24 Nov 2000, Thomas Proell wrote:
> 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)
Try with 50-60MB file, use the result from the second test,
i.e. when the file is cached in the ftp server. You can achieve more
than 11MB/sec.
> 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%.
No, the rp_filter usage is not related to the net performance.
Use this on the real server:
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth0/rp_filter
For more info:
less /usr/src/linux/Documentation/proc.txt
When using testlvs with reject rule in the real server, setting
rp_filter to 1 in the real server (if it is Linux) allows the packets
10/8 -> VIP to be dropped as source martians. By this way they don't
reach the input SYN queue (no SYN cookies generated). So, use rp_filter
to help the real server to survive the flood. The alternative is to use
ipchains -I input -s 10.0.0.0/8 -d VIP -j DENY
> 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%
May be you need to update to the recent procps 2.0.*:
ps --version
May be the memory in the director is not used only from LVS.
150,000 entries mean 19MB memory and this is too low for 256MB
director.
> Regards
>
> Thomas
Regards
--
Julian Anastasov <ja@xxxxxx>
|
