|
Hello,
On Thu, 7 Jun 2001, Joseph Mack wrote:
> > > 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.
> >
> > Yes, Ratz's code adds limits per service while this sysctl can
> > limit everything. Or it can be additional strategy (oh, another one)
> > vs/lowmem. The semantic can be "Don't allocate memory for new connections
> > when the low memory threshold is reached". It can work for the
> > masquerading connections too (2.2). By this way we will reserve memory
> > for the user space. Very dangerous option, though.
>
> what's dangerous about it?
One user process can allocate too much memory and to cause
the LVS to drop new connections because the lowmem threshold is reached.
> > May be conn_limit is
> > better or something like this:
> >
> > if (conn_number > min_conn_limit && free_memory < lowmem_thresh)
> > DROP_THIS_PACKET_FOR_NEW_CONN
>
> why have a min_conn_limit in here? If you put more memory into the director,
> then you'll have to recompile your kernel. Is it because finding
> conn_number is cheaper than finding free_memory?
:) The above example with real numbers:
if (conn_number > 500000 && free_memory < 10MB) DROP
I.e. don't allow the user processes to use memory that LVS
can use. But when there are "enough" LVS connections created we can
consider reserving 10MB for the user space and to start dropping
new connections early, i.e. when there are less than 10MB free memory.
If conn_number < 500000 LVS simply will hit the 0MB free memory point
and the user space will be hurted because these processes allocated
too much memory in this case.
> > But obtaining the "free_memory" may be costs CPU cycles. May be we can
> > stick with a snapshot on each second.
>
> The number of valid connections shouldn't change dramatically
> in 1 sec. However a DoS might still cause problems.
Yes, the problem is on SYN attack.
> Joe
Regards
--
Julian Anastasov <ja@xxxxxx>
|
