LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: hash table size

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx, Julian Anastasov <ja@xxxxxx>
Subject: Re: hash table size
Cc: Joseph Mack <mack.joseph@xxxxxxxxxxxxxxx>, Roberto Nibali <ratz@xxxxxx>
From: Joseph Mack <mack.joseph@xxxxxxx>
Date: Thu, 07 Jun 2001 09:42:07 -0400
Julian Anastasov wrote:

>         Hm, I don't remember such semantic. May be Wensong does :)

I forget, you are new to this project :-)

>         The last 2 lines are wrong. 

OK

>         Here is the picture:

OK


> > I'm looking in 0.9.1-2.4.5 /proc/sys/net/ipv4/vs and don't
> > see it (I have amemthresh, timeout*, drop*)
> 
>         This is an idea I'm proposing to you if the defense
> strategies are not triggered fast enough to follow the incoming
> packet rate :))

We can't let the director crash if the director doesn't have 
enough memory for valid connections either. 
We don't want directors going down and sysadmins having to be called in
at night to figure out what happened, when all that happened was that the
director ran out of memory. It's OK if the director drops packets and nothing
gets through, but the director can't crash. 

 It is not implemented yet :) It is not hard to do,
> the patch will be short:
> 
> value 0 => no limit
> value > 0 => limit of the number of connections

simple to maintain :-)
 
> for example:
> 
> echo 300000 > /proc/sys/net/ipv4/vs/conn_limit
> 
> => max 38MBytes for connections
> 
> this is a blind DoS prevention :)))
> 
> > Will it limit the memory the hash table can use?
> 
>         Sure, once implemented :) Of course, it should be coordinated
> with the other objects that allocate memory: the processes, etc. And
> this is not a limit of the used hash table memory, it is a limit in
> the number of connections and so in the memory they allocate. We
> allocate memory for the hash table only once, at boot.

I looked at Ratz's code, and that's going to have to be ported to 2.4
and maintained with each upgrade. Your patch doesn't address his problems,
but does fix my concerns.

Joe
-- 
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center, 
mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA


<Prev in Thread] Current Thread [Next in Thread>