Re: /proc/self/oom_adj is deprecated in newer Linux kernels
От | Andres Freund |
---|---|
Тема | Re: /proc/self/oom_adj is deprecated in newer Linux kernels |
Дата | |
Msg-id | 20140610154536.GN8406@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: /proc/self/oom_adj is deprecated in newer Linux kernels (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On 2014-06-10 11:35:23 -0400, Robert Haas wrote: > > Because it would convert the intended behavior (postmaster and only > > postmaster is exempt from OOM kill) into a situation where possibly > > all of the database processes are exempt from OOM kill, at the whim > > of somebody who should not have the privilege to decide that. > > Gurjeet already refused that argument. Only that he was wrong: ~# echo -500 > /proc/$BASHPID/oom_score_adj ~# su andres ~$ echo -1000 > /proc/$BASHPID/oom_score_adj bash: echo: write error: Permission denied # so I can't decrease the likelihood ~$ echo -400 > /proc/$BASHPID/oom_score_adj # but I can increase it ~$ echo -500 > /proc/$BASHPID/oom_score_adj # but also *reset* it Since we have to do the adjustment after the fork - otherwise the postmaster would be vulnerable for a time - normal backends can reset their score. > Apparently, the child > processes can only increase their chance of being OOM-killed, not > decrease it, so you have this exactly backwards: right now, an > individual system administrator can exempt all of the database > processes from OOM kill, but cannot exempt the postmaster alone. Well, if you compile postgres with the #define it'll reset the likelihood after the fork? That's the reset? Or do you mean without compiling postgres with the option? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: