Message-ID: <5339865C.9020209@aklaver.com>
Date: Mon, 31 Mar 2014 08:14:36 -0700
From: Adrian Klaver <adrian.klaver@aklaver.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Willy-Bas Loos <willybas@gmail.com>, lst_hoe02@kwsoft.de,
 pgsql-admin <pgsql-admin@postgresql.org>,
 "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
Subject: Re: [ADMIN]openvz and shared memory trouble
References: 
 <CAHnozTjxUrfbaZVFbzibLQmhzR-n9ty+ktyRN2a0Tyr9PhApqQ@mail.gmail.com>
 <53357E83.2040101@aklaver.com>
 <CAHnozThQ9WkE+b3b1kXGpgNfnpP6NsxpFNSmvgsw_ZnqGfc+CA@mail.gmail.com>
 <53370026.2040509@aklaver.com>
 <CAHnozTjVQeisMGKPsPMbYJ=_jqBNNvZ81x0ohRuta364J9cdmg@mail.gmail.com>
 <53397DE7.2070903@aklaver.com> <15934.1396278062@sss.pgh.pa.us>
In-Reply-To: <15934.1396278062@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-general-owner@postgresql.org

On 03/31/2014 08:01 AM, Tom Lane wrote:
> Adrian Klaver <adrian.klaver@aklaver.com> writes:
>> On 03/31/2014 04:12 AM, Willy-Bas Loos wrote:
>>> I'm still worried that it's like Tom Lane said in another discussion:"So
>>> basically, you've got a broken kernel here: it claimed to give PG circa
>>> (135MB) of memory, but what's actually there is only about (128MB). I
>>> don't see any connection between those numbers and the shmmax/shmall
>>> settings, either --- so I think this must be some busted implementation
>>> of a VM-level limitation."
>>> (here:
>>> http://www.postgresql.org/message-id/CAK3UJREBcyVBtr8D7vMfU=uDdkjXkrPnGcuy8erYB0tMfKe1LA@mail.gmail.com)
>>>
>>> And it makes me wonder what else may be issues that arise from that. But
>>> especially, what i can do about it.
>
> FWIW, I went back and re-read that message while perusing this thread,
> and this time it struck me that there was a significant bit of evidence
> I'd overlooked: namely, that the buffer block array is by no means the
> last thing in Postgres' shared memory segment.  There are a bunch of
> other shared data structures allocated after it, some of which almost
> certainly had to have been touched by the startup subprocess.  The gdb
> output makes it clear that the kernel stopped providing memory at
> 0xb6c4b000; but either it resumed doing so further on, or the whole shared
> memory segment *had* been provisioned originally, and then part of it
> got unmapped again while the startup process was running.
>
> So it's still clearly a kernel bug, but it seems less likely that it is
> triggered by some static limit on shared memory size.  Perhaps instead,
> the kernel had been filling in pages for the shared segment on-demand,
> and then when it got to some limit it refused to do so anymore and allowed
> a SIGBUS to happen instead.
>
>> I do not use openvz so I do not have a test bed to try out, but this
>> page seems to be related to your problem:
>> http://openvz.org/Resource_shortage
>> or if you want more detail and a link to what looks to a replacement for
>> beancounters:
>> http://openvz.org/Setting_UBC_parameters
>
> If this software's idea of resource management is to allow SIGBUS to
> happen upon attempting to use memory that had been successfully granted,
> then it's a piece of junk that you should get rid of ASAP.  (No, I
> don't like Linux's OOM-kill solution to resource overcommit either.)

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.


>
> 			regards, tom lane
>
>


-- 
Adrian Klaver
adrian.klaver@aklaver.com


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general