Re: /proc/self/oom_adj is deprecated in newer Linux kernels
От | David G Johnston |
---|---|
Тема | Re: /proc/self/oom_adj is deprecated in newer Linux kernels |
Дата | |
Msg-id | 1402420419997-5806700.post@n5.nabble.com обсуждение исходный текст |
Ответ на | Re: /proc/self/oom_adj is deprecated in newer Linux kernels (Gurjeet Singh <gurjeet@singh.im>) |
Ответы |
Re: /proc/self/oom_adj is deprecated in newer Linux kernels
|
Список | pgsql-hackers |
Gurjeet Singh-4 wrote > Even if the clueless DBA tries to set the oom_score_adj below that of > Postmaster, Linux kernel prevents that from being done. I demonstrate > that in the below screen share. I used GUC as well as plain command > line to try and set a child's badness (oom_score_adj) to be lower than > that of Postmaster's, and Linux disallows doing that, unless I use > root's powers. > > So the argument that this GUC is a security concern, can be ignored. > Root user (one with control of start script) still controls the lowest > badness setting of all Postgres processes. If done at fork_process > time, the child process simply inherits parent's badness setting. The counter point here is that the postmaster can be set to "no kill" and the >= condition allows for children to achieve the same while it is our explicit intent that the children be strictly > parent. To that end, should the adjustment value be provided as an offset to the postmasters instead of an absolute value - and disallow <= zero offset values in the process? I get and generally agree with the environment variable proposal and it's stated goal to restrict whom can makes changes. But how much less cost does an environment variable have than a GUC if one GUC argument is still its maintenance overhead? David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/proc-self-oom-adj-is-deprecated-in-newer-Linux-kernels-tp4810971p5806700.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
В списке pgsql-hackers по дате отправления: