Re: Pre-allocation of shared memory ...
От | Andrew Dunstan |
---|---|
Тема | Re: Pre-allocation of shared memory ... |
Дата | |
Msg-id | 33593.199.90.235.43.1055424917.squirrel@www.dunslane.net обсуждение исходный текст |
Ответ на | Re: Pre-allocation of shared memory ... (Hans-Jürgen Schönig <hs@cybertec.at>) |
Ответы |
Re: Pre-allocation of shared memory ...
|
Список | pgsql-hackers |
On this machine (RH9, kernel 2.4.20-18.9) the docs say (in /usr/src/linux-2.4/Documentation/vm/overcommit-accounting ): ----------------- The Linux kernel supports four overcommit handling modes 0 - Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for atypical system. It ensures a seriously wild allocation fails while allowing overcommit to reduceswap usage 1 - No overcommit handling. Appropriate for some scientific applications 2 - (NEW) strict overcommit. The total address space commit for the system is not permitted toexceed swap + half ram. In almost all situations this means a process will not be killed whileaccessing pages but only by malloc failures that are reported back by the kernel mmap/brk code. 3 - (NEW) paranoid overcommit The total address space commit for the system is not permitted toexceed swap. The machine will never kill a process accessing pages it has mapped except dueto a bug (ie report it!) ---------------------- So maybe sysctl -w vm.overcommit_memory=3 is what's needed? I guess you might pay a performance hit for doing that, though. andrew > > Yeah, I see it in the Mandrake kernel. But it's not in stock 2.4.19, > > so you can't assume everybody has it. > > > > We had this problem on a recent version of good old Slackware. > I think we also had it on RedHat 8 or so. > > Doing this kind of killing is definitely a bad habit. I thought it had > it had to do with something else so my proposal for pre-allocation > seems to be pretty obsolete ;). > > Thanks a lot. > > Hans
В списке pgsql-hackers по дате отправления: