Re: Pre-allocation of shared memory ...

Поиск
Список
Период
Сортировка
От Ron Mayer
Тема Re: Pre-allocation of shared memory ...
Дата
Msg-id POEDIPIPKGJJLDNIEMBEKELGCPAA.ron@intervideo.com
обсуждение исходный текст
Ответ на Re: Pre-allocation of shared memory ...  ("Jeroen T. Vermeulen" <jtv@xs4all.nl>)
Ответы Re: Pre-allocation of shared memory ...  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Re: Pre-allocation of shared memory ...  ("Jeroen T. Vermeulen" <jtv@xs4all.nl>)
Список pgsql-hackers
Jeroen T. Vermeulen wrote:
>
>After that, where do you go?  Try to find a reasonable process to shoot
>in the head.  From what I heard, although I haven't kept current, a lot
>of work went into selecting a "reasonable" process, so there will be some
>determinism.

FWIW, you can browse the logic linux uses to choose 
which process to kill here: http://lxr.linux.no/source/mm/oom_kill.c

If I read that right, this calculates "points" for each process, where:  points = vm_size_of_process            /
sqrt(cpu_time_it_ran)          / sqrt(sqrt(clock_time_it_had)           * 2 if the process was niced           / 4 if
theprocess ran a root           / 4 if the process had hardware access.
 
and whichever process has the most points dies.

I'm guessing any database backend (postgres, oracle)
that wasn't part of a long-lived connection seems like 
an especially attractive target to this algorithm.  

(Though hopefully it's all moot now that Andrew / Tomfound/recommended the paranoid overcommit option, whichsure seems
likethe most sane thing for a server to me)
 
  Ron

PS: Oracle DBAs suffer from the same pain.  http://www.cs.helsinki.fi/linux/linux-kernel/2001-12/0098.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0103.3/0094.html




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Pre-allocation of shared memory ...
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Pre-allocation of shared memory ...