Re: /proc/self/oom_adj is deprecated in newer Linux kernels
От | Robert Haas |
---|---|
Тема | Re: /proc/self/oom_adj is deprecated in newer Linux kernels |
Дата | |
Msg-id | CA+TgmoaOA+9GMQBuhTONwJ2jOHfC_-+Ck2osjaMz6-eksQ0O8w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: /proc/self/oom_adj is deprecated in newer Linux kernels (Christoph Berg <cb@df7cb.de>) |
Ответы |
Re: /proc/self/oom_adj is deprecated in newer Linux kernels
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: /proc/self/oom_adj is deprecated in newer Linux kernels (Jonathan Corbet <corbet@lwn.net>) |
Список | pgsql-hackers |
On Tue, Jul 1, 2014 at 8:22 AM, Christoph Berg <cb@df7cb.de> wrote: > Re: Tom Lane 2014-06-23 <17054.1403542164@sss.pgh.pa.us> >> > While I'd love to reduce the number of future installations without >> > this fix in place, I respect the decision to honor project policy. At >> > the same time, this change does not break anything. It introduces new >> > environment variables which change the behaviour, but behaves the old >> > way in the absence of those variables. >> >> Uh, no, it doesn't. We removed the dependence on -DLINUX_OOM_SCORE_ADJ. >> If a packager is expecting that to still work in 9.4, he's going to be >> unpleasantly surprised, because the system will silently fail to do what >> he's expecting: it will run all the backend processes at no-OOM-kill >> priority, which is likely to be bad. > > Ok I'm late to the party, but the reason I'm still joining is we have > proper unit tests which just told me the 9.5 packages have changed OOM > handling. So it wouldn't just slip through if you changed that in 9.4 > as well, but would get fixed. > > I have two comments on the patch: > > The choice to make the behavior depend first on PG_OOM_ADJUST_FILE and > only secondly on PG_OOM_ADJUST_VALUE seems the wrong way round to me. > On every modestly new kernel oom_score_adj is present, so > PG_OOM_ADJUST_FILE should default to using it. On the other hand, what > people really want to achieve (or tune) with this feature is to set > the OOM adjustment back to 0 (or some other value), so to me, it would > be much more natural to set PG_OOM_ADJUST_VALUE=0 to activate the > feature, and only have to mess with PG_OOM_ADJUST_FILE if my kernel is > older. (Which it isn't on any kernel supported by Debian and Ubuntu > LTS.) Of course, we have no guarantee that the Linux kernel guys won't change this again. Apparently "we don't break userspace" is a somewhat selectively-enforced principle. > The other bit is the non-deprecation of OOM_ADJ in > contrib/start-scripts/linux. It took me a while to understand the > logic of the variables used there - the interface would be much > clearer if it just was like this: > > ... set default PG_OOM_ADJUST_FILE=/proc/self/oom_score_adj > > ... and then this in the configurable part of the script: > > PG_MASTER_OOM_SCORE_ADJ=-1000 > PG_OOM_SCORE_ADJ=0 > # Older Linux kernels may not have /proc/self/oom_score_adj, but instead > # /proc/self/oom_adj, which works similarly except the disable value is -17. > # For such a system, uncomment these three lines instead. > #PG_OOM_ADJUST_FILE=/proc/self/oom_adj > #PG_MASTER_OOM_SCORE_ADJ=-17 > #PG_OOM_SCORE_ADJ=0 > > ... and then use PG_OOM_ADJUST_FILE below instead of manually figuring > out which proc file to write to by looking at OOM.*_ADJ. I can't help but agree with this, though. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: