|
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, 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.
> 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'`
|
