|
Hi Julian,
> > 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 :)))
Remember when it would kill the init process? :))
> > 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.
You're right.
> 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
[...]
> 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.
Julian, it's too complicated and there is too little use for such a
biest. It's an interesting discussing topic but only of theoretical
use.
Take care,
Roberto Nibali, ratz
--
mailto: `echo NrOatSz@xxxxxxxxx | sed 's/[NOSPAM]//g'`
|
