Re: Setting oom_adj on linux?
От | Alex Hunsaker |
---|---|
Тема | Re: Setting oom_adj on linux? |
Дата | |
Msg-id | 34d269d41001071946u72dee551kccb1182aebfcee61@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Setting oom_adj on linux? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Setting oom_adj on linux?
Re: Setting oom_adj on linux? |
Список | pgsql-hackers |
On Thu, Jan 7, 2010 at 20:26, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Alex Hunsaker <badalex@gmail.com> writes: > We can either drop this in core (with a lot of #ifdef LINUX added) Any thoughts on doing something like (in fork_process.c) #ifdef LINUX void oom_adjust() { ... } #else void oom_adjust() {} #endif So there is only one #ifdef? It still leaves the ugly calls to the function... > or expect Linux packagers to carry it as a patch. Given that the > packagers would also have to modify their init scripts to go with, > the patch route is not unreasonable. Comments? Id plus +1 for core. The problem certainly does not look to be going away soon (if ever). >> This has some oddities like it does not reset oom to 0 for the (wal) >> writer process. > > FWIW, I think that's probably a feature --- I'd vote for only resetting > in regular backends and possibly autovac workers. I think that makes sense +1. In-fact thats why the patch has it as a separate function instead of hacked into fork_process(). However its mainly odd because IIRC I greped for all instances of fork_process() and added the oom_adjusting to the callers. Given that it seems the wall writer procs should also be set to 0. My guess is its a race with my startup script launching postgres and then setting oom_adj. Or maybe I missed a caller? Maybe they don't use fork_process()? Ill check it out.
В списке pgsql-hackers по дате отправления: