Re: Can't find thread on Linux memory overcommit
От | Andrew Dunstan |
---|---|
Тема | Re: Can't find thread on Linux memory overcommit |
Дата | |
Msg-id | 3F450486.50907@dunslane.net обсуждение исходный текст |
Ответ на | Re: Can't find thread on Linux memory overcommit (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
(er, that's "Andrew" :-) It depends how important your data is to you. A modest server probably costs a few thousand dollars. How much does an expert to install a custom kernel cost? Probably about the same. I believe paranoid mode is supposed to prevent any overcommiting that can't later be honoured when the process comes to map the memory, and strict mode is supposed to do the same in most normal circumstances. Maybe someone more expert in kernel hackery than I am can give a better answer. BTW, Alan Cox is going on sabbatical from RH very soon - so there will be no more -ac patches. By the time he returns 2.6 should have been released and bedded down, with any luck. andrew Josh Berkus wrote: >Alan, > > > >>You need to be careful using Alan's patch. The reason RH stopped using >>this part of it in their errata kernels is that it had conflicts with >>other stuff, specifically the rmap stuff (he told me that himself in >>email). >> >> > >Hmmm ... that leaves us without a workaround for this problem, then, yes? >Because even parnoid-mode kernels you can discourage, but not prevent, >overcommitting. > > > >>For mission critical apps I would advise running the postmaster on a >>dedicated machine, with no X or other nasty stuff running. >> >> > >Unfortunately, this is frequently not an option ... PostgreSQL is often >together on a server with Apache, a JVM, and other server software. As >happened in the one case of possible (diagnosis pending) failure that we are >looking into. Of course, it could be something else .... > > >
В списке pgsql-hackers по дате отправления: