On 03/31/2014 08:28 AM, Tom Lane wrote:
> Adrian Klaver <adrian.klaver@aklaver.com> writes:
>> At this point the memory allocation as a problem is as much conjecture
>> as anything else, at least to me. So what is causing SIGBUS is an open
>> question in my mind.
>
> Agreed, it's unproven what's causing the SIGBUS in the case at hand.
> However, in the case I investigated for Josh Kupershmidt, it was provably
> the fault of the kernel for failing to supply memory to back the shared
> memory segment that it had previously agreed to allocate. The fact that
> both users are trying to run their standby server under OpenVZ is, shall
> we say, merely suggestive.
Yes, the fact that the problem seems to go away with a change in
shared_buffers seems to point in that direction also. To get through the
smoke to the fire, there are more questions to be answered:
1) The OP says the shared_buffered setting that failed was 4GB and that
'tuning' down the setting solved the problem. So it would be nice to
know what setting worked?
2) In hand with 1), the memory settings for the virtualization host and
the container(s) involved are?
3) What is the host OS?
4) What version of OpenVZ?
5) What is the layout?
Are the primary and standby on the same container, different containers
or some other arrangement?
In other words could there be some other resource conflict going on, say
network?
6) Are the crashes random or do they follow some pattern?
>
> regards, tom lane
>
--
Adrian Klaver
adrian.klaver@aklaver.com