2011/6/17 Антон Степаненко <zlobnyni...@yandex.ru>: >> >> 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.
No, that's all correct, but I smell a rat. Could be the virtualization software, not sure. But the problem looks not to be with postgres...the server is just reporting o/s calls that are returning with error. merlin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
