From: Tom Lane <tgl@sss.pgh.pa.us>
To: Adrian Klaver <adrian.klaver@aklaver.com>
Cc: Willy-Bas Loos <willybas@gmail.com>
Cc: lst_hoe02@kwsoft.de, pgsql-admin <pgsql-admin@postgresql.org>
Cc: pgsql-general@postgresql.org <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] openvz and shared memory trouble
Date: Mon, 31 Mar 2014 11:01:02 -0400
Message-ID: <15934.1396278062@sss.pgh.pa.us> (raw)
In-Reply-To: <53397DE7.2070903@aklaver.com>
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-admin>
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....)
>>
>> 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.)
regards, tom lane
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: tgl@sss.pgh.pa.us, adrian.klaver@aklaver.com, willybas@gmail.com, pgsql-general@postgresql.org
Subject: Re: [GENERAL] openvz and shared memory trouble
In-Reply-To: <15934.1396278062@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox