LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: hash table size

To: Joseph Mack <mack.joseph@xxxxxxx>
Subject: Re: hash table size
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx, Joseph Mack <mack.joseph@xxxxxxxxxxxxxxx>, Roberto Nibali <ratz@xxxxxx>
From: Julian Anastasov <ja@xxxxxx>
Date: Thu, 7 Jun 2001 17:03:01 +0300 (EEST)
        Hello,

On Thu, 7 Jun 2001, Joseph Mack wrote:

> >         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.

        Yes, the packets are dropped because there is no space to
create new connection structure. The IPVS in the kernel will not crash
but something else in the box will do, soon or later.

> 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. 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

But obtaining the "free_memory" may be costs CPU cycles. May be we can
stick with a snapshot on each second.

> 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


Regards

--
Julian Anastasov <ja@xxxxxx>



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