Re: could not read block XXXXX in file "base/YYYYY/ZZZZZZ": read only 160 of 8192 bytes

2011/6/17 Антон Степаненко <zlobnynigga(at)yandex(dot)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