> > I wonder if you are oversubscribing your memory, and are getting weird > errors when reading data into memory because the pages can't be > reserved to do that. What happens when you enable overcommit and > attempt to start the server? > > merlin
In my first post I wrote: "I tried to set vm.overcommit_memory=2 and vm.overcommit_ratio=90 - no sense. Then I tried vm.overcommit_memory=1 - no sense." "No sense" means that server starts, works for about 3 hours, and then dies with signal 7 and almost all buffers filled. Just as with vm.overcommit_memory=0. I copypasted vmstat log, that shows that there were 5Gb of free memory when postgresql died. In one of my experiments postgresql worked for about half an hour with 0k free memory (at least top and vmstat said so). Abscence of free memory was caused by the fact that replica had been down for 12 hours or so, and when started wal writer procees took much resources. But it was woking! With no free memory. But this is not important. As I noticed the thing is not how much free memory I have. The thing is how shared buffers are filled. And shared buffers fillings makes sense only when they are set to 12Gb. When they set to less - everything works fine. If I am oversubcribing memory - then I expect to get some "out of memory error" and see 0k free in top output. Memory for shared buffers can not be ovesubscribed - because if kernel did not provide enough shared memory postgres will not start. If I am wrong - please, explain why and where. -- Sent via pgsql-bugs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
