Re: configurability of OOM killer
От | Tom Lane |
---|---|
Тема | Re: configurability of OOM killer |
Дата | |
Msg-id | 11881.1202054192@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: configurability of OOM killer (Martijn van Oosterhout <kleptog@svana.org>) |
Список | pgsql-hackers |
Martijn van Oosterhout <kleptog@svana.org> writes: > Now, postgres almost certainly will never change much of it so it's not > a big deal, but it could if it wanted to and that what overcommit was > designed for: banking on the fact that 99% of the time, that space > isn't written to. Overcommit is precisely what makes forking as cheap > as threads. Nonsense. Copy-on-write is what makes forking as cheap as threads. Now it's true that strict accounting requires the kernel to be prepared to make a lot of page copies that it will never actually need in practice. In my mind that's what swap space is for: it's the buffer that the kernel *would* need if there were suddenly a lot more copies-on-write than it'd been expecting. As already noted, code pages are generally read-only and need not factor into the calculation at all. I'm not sure how much potentially-writable storage is really forked off by the postmaster, but I doubt it's in the tens-of-MB range. regards, tom lane
В списке pgsql-hackers по дате отправления: