|
Hello,
On Fri, 8 Jun 2001, Roberto Nibali wrote:
> Hello,
>
> > 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.
>
> In kernel 2.4.x you can hope for the OOM killer that this will not happen,
> but as the history shows, we haven't yet found a decent way to handle the
> OOM problem.
Yes, only when you read the word "killer" you will understand
what can happen with the user processes :))) Why it is not named
OOM manager or something better :))) Because it is too late :)))
> > 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
>
> I kinda like it but as you said, there is the amem_thresh, my approach
> (which was not actually done because of this problem :) and now having
> a lowmem_thresh. I think this will end up in a orthogonal semantic for
> memory allocation. For example if you enable the amem_thresh the
> conn_number > min_conn_limit && free_memory < lowmem_thresh would never
> be the case. OTOH if you set the lowmem_thresh to low the amem_thresh
> is ineffective. My patch would suffer from this too.
lowmem_thresh is not related to amemthresh but when
amemthresh < lowmem_thresh the strategies will never be activated.
lowmem_thresh should be less than amemthresh. Then the strategies
will try to keep the free memory in the lowmem_thresh:amemthresh range
instead of the current range 0:amemthresh
Example (I hope you have memory to waste):
lowmem_thresh=16MB (think of it as reserved for user processes and kernel)
amemthresh=32MB (when the defense strategies trigger)
min_conn_limit=500000 (think of it as 60MB reserved for LVS connections)
So, the conn_number can grow far away after min_conn_limit but
only while lowmem_thresh is not reached. If conn_number < 500000 and
free_memory < lowmem_thresh we will wait the OOM killer to help us.
So, we have 2 tuning parameters: the desired number of connections
and some space reserved for user processes. And may be this is difficult
to tune, we don't know how the kernel prevents problems in VM before
activating the killer, i.e. swapping, etc. And the cluster software
can take some care when allocating memory.
> > But obtaining the "free_memory" may be costs CPU cycles. May be we can
> > stick with a snapshot on each second.
>
> Ugly, IMHO. We rather do another snapshot every second :)
>
> Best regards,
> Roberto Nibali, ratz
>
> --
> mailto: `echo NrOatSz@xxxxxxxxx | sed 's/[NOSPAM]//g'`
Regards
--
Julian Anastasov <ja@xxxxxx>
|
