Обсуждение: Problems with huge_pages and IBM Power8

Hi

We have been doing some testing with Postgres (9.5.2) compiled on a Power8 running Centos 7

When working with huge_pages, we initially got this error.

munmap(0x3efbe4000000) failed: Invalid argument

after a bit of investigation we noticed that hugepagesize is har coded to 2MB

src/backend/port/sysv_shmem.c (ligne 360)
...
int                     hugepagesize = 2 * 1024 * 1024;

But on the power they were configured to 16MB.  Recompiling to 16MB (8 * 1024 * 1024) and we had no problems with the
tests.

My initial questions are.

1 what is the hugepagesize hard coded to 2MB?
2 are there any side effect in setting it to 16MB?
3 since on the poer hugepages can have different values, would it be possible to have this value configurable?

Going further, we tried testing hugepages also on Ubuntu 16.04, also on the power8.  On Ubuntu Postgres did not like
thehugepages at all (set also to 16MB)  and consistently crashed. 

Looking for some insight into this issue.  the error from the postgres log on ubuntu is below.
It apperas to be related to semephores.

I don't have the compile optiona at the moment, I can provide those are other detais as needed.

Reiner

2016-04-12 12:26:42 CEST : 0 FATAL:  semctl(7864340, 14, SETVAL, 0) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  server process (PID 13352) exited with exit code 1
2016-04-12 12:26:42 CEST : 0 LOG:  terminating any other active server processes
2016-04-12 12:26:42 CEST facturation:system_dba 0 10.32.32.200WARNING:  terminating connection because of crash of
anotherserver process 
2016-04-12 12:26:42 CEST facturation:system_dba 0 10.32.32.200DETAIL:  The postmaster has commanded this server process
toroll back the current transaction and exit, because another server process exited abnormally and possibly corrupted
sharedmemory. 
2016-04-12 12:26:42 CEST facturation:system_dba 0 10.32.32.200HINT:  In a moment you should be able to reconnect to the
databaseand repeat your command. 
2016-04-12 12:26:42 CEST postgres:admin 0 10.32.16.3WARNING:  terminating connection because of crash of another server
process
2016-04-12 12:26:42 CEST postgres:admin 0 10.32.16.3DETAIL:  The postmaster has commanded this server process to roll
backthe current transaction and exit, because another server process exited abnormally and possibly corrupted shared
memory.
2016-04-12 12:26:42 CEST postgres:admin 0 10.32.16.3HINT:  In a moment you should be able to reconnect to the database
andrepeat your command. 
2016-04-12 12:26:42 CEST postgres:perf_user 0 ::1WARNING:  terminating connection because of crash of another server
process
2016-04-12 12:26:42 CEST postgres:perf_user 0 ::1DETAIL:  The postmaster has commanded this server process to roll back
thecurrent transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 
2016-04-12 12:26:42 CEST postgres:perf_user 0 ::1HINT:  In a moment you should be able to reconnect to the database and
repeatyour command. 
2016-04-12 12:26:42 CEST : 0 WARNING:  terminating connection because of crash of another server process
2016-04-12 12:26:42 CEST : 0 DETAIL:  The postmaster has commanded this server process to roll back the current
transactionand exit, because another server process exited abnormally and possibly corrupted shared memory. 
2016-04-12 12:26:42 CEST : 0 HINT:  In a moment you should be able to reconnect to the database and repeat your
command.
2016-04-12 12:26:42 CEST : 0 LOG:  all server processes terminated; reinitializing
2016-04-12 12:26:42 CEST : 0 LOG:  could not remove shared memory segment "/PostgreSQL.1612071802": No such file or
directory
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7274497, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7307267, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7340036, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7372805, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7405574, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7438343, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7471112, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7503881, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7536650, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7569419, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7602188, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7634957, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7667726, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7700495, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7733264, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7766033, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7798802, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7831571, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7864340, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:42 CEST : 0 LOG:  semctl(7897109, 0, IPC_RMID, ...) failed: Invalid argument
2016-04-12 12:26:43 CEST : 0 LOG:  database system was interrupted; last known up at 2016-04-12 12:22:08 CEST
2016-04-12 12:26:43 CEST : 0 LOG:  database system was not properly shut down; automatic recovery in progress
2016-04-12 12:26:43 CEST : 0 LOG:  redo starts at 0/1FDD8F0
2016-04-12 12:26:43 CEST : 0 LOG:  invalid record length at 0/20344B0
2016-04-12 12:26:43 CEST : 0 LOG:  redo done at 0/2034488
2016-04-12 12:26:43 CEST : 0 LOG:  last completed transaction was at log time 2016-04-12 12:26:01.704901+02

On 2016-04-12 21:58:14 +0200, reiner peterke wrote:
> Hi
> 
> We have been doing some testing with Postgres (9.5.2) compiled on a Power8 running Centos 7
> 
> When working with huge_pages, we initially got this error.
> 
> munmap(0x3efbe4000000) failed: Invalid argument

*munmap*, not mmap failed? that's odd; because there the hugepagesize
shouldn't have much of an influence. If something fails it should be the
initial mmap.  Could you show a strace of a failed start with an
unmodified postgres?

> after a bit of investigation we noticed that hugepagesize is har coded
> to 2MB

Note it's not actually hardcoded to some size. It's just about rounding
the size to a multiple of 2MB due to an older kernel bug:    /*     * Round up the request size to a suitable large
value.    *     * Some Linux kernel versions are known to have a bug, which causes     * mmap() with MAP_HUGETLB to
failif the request size is not a     * multiple of any supported huge page size. To work around that, we     * round up
therequest size to nearest 2MB. 2MB is the most common     * huge page page size on affected systems.
 


> Going further, we tried testing hugepages also on Ubuntu 16.04, also on the power8.  On Ubuntu Postgres did not like
thehugepages at all (set also to 16MB)  and consistently crashed.
 

> Looking for some insight into this issue.  the error from the postgres
> log on ubuntu is below.  It apperas to be related to semephores.

I've a bit of a hard time believing that this is related to huge pages.


Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> On 2016-04-12 21:58:14 +0200, reiner peterke wrote:
>> Looking for some insight into this issue.  the error from the postgres
>> log on ubuntu is below.  It apperas to be related to semephores.

> I've a bit of a hard time believing that this is related to huge pages.

I'm betting that's this:

http://www.postgresql.org/message-id/CAK7tEys9-O4BTERbs3Xuk2BfFNNd55u2sM9j5R2Fi7v6BHjrQw@mail.gmail.com
        regards, tom lane

> On Apr 12, 2016, at 10:20 PM, Andres Freund <andres@anarazel.de> wrote:
>
> On 2016-04-12 21:58:14 +0200, reiner peterke wrote:
>> Hi
>>
>> We have been doing some testing with Postgres (9.5.2) compiled on a Power8 running Centos 7
>>
>> When working with huge_pages, we initially got this error.
>>
>> munmap(0x3efbe4000000) failed: Invalid argument
>
> *munmap*, not mmap failed? that's odd; because there the hugepagesize
> shouldn't have much of an influence. If something fails it should be the
> initial mmap.
I’ll double check in the morning, but i did copy it from the log.

> Could you show a strace of a failed start with an
> unmodified postgres?

we didn’t have the error when not using huge_pages.

>> after a bit of investigation we noticed that hugepagesize is har coded
>> to 2MB
>
> Note it's not actually hardcoded to some size. It's just about rounding
> the size to a multiple of 2MB due to an older kernel bug:
>         /*
>          * Round up the request size to a suitable large value.
>          *
>          * Some Linux kernel versions are known to have a bug, which causes
>          * mmap() with MAP_HUGETLB to fail if the request size is not a
>          * multiple of any supported huge page size. To work around that, we
>          * round up the request size to nearest 2MB. 2MB is the most common
>          * huge page page size on affected systems.
>
>
>> Going further, we tried testing hugepages also on Ubuntu 16.04, also on the power8.  On Ubuntu Postgres did not like
thehugepages at all (set also to 16MB)  and consistently crashed. 
>
>> Looking for some insight into this issue.  the error from the postgres
>> log on ubuntu is below.  It apperas to be related to semephores.
>
> I've a bit of a hard time believing that this is related to huge pages.

Well all i have at the moment is that when we disabled huge pages on the kernel level and then restarted postgres there
wereno additional crashes. 
Unfortunately I cannot access the server now.  I will look further tomorrow.


>
>
> Greetings,
>
> Andres Freund

Sincerely,

Reiner Peterke

reiner peterke <zedaardv@drizzle.com> writes:
>> On Apr 12, 2016, at 10:20 PM, Andres Freund <andres@anarazel.de> wrote:
>> I've a bit of a hard time believing that this is related to huge pages.

> Well all i have at the moment is that when we disabled huge pages on the kernel level and then restarted postgres
therewere no additional crashes.
 

That log excerpt shows pretty conclusively that both your semaphores and
your shared memory were yanked out from under you.  That's not a Postgres
bug, and it seems unlikely to be related to huge pages either.
        regards, tom lane

> On Apr 12, 2016, at 10:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Andres Freund <andres@anarazel.de> writes:
>> On 2016-04-12 21:58:14 +0200, reiner peterke wrote:
>>> Looking for some insight into this issue.  the error from the postgres
>>> log on ubuntu is below.  It apperas to be related to semephores.
>
>> I've a bit of a hard time believing that this is related to huge pages.
>
> I'm betting that's this:
>
> http://www.postgresql.org/message-id/CAK7tEys9-O4BTERbs3Xuk2BfFNNd55u2sM9j5R2Fi7v6BHjrQw@mail.gmail.com
>
>             regards, tom lane

Hi Tom,

You appear to have been correct.  :-)
The being led to believe it was connected to huge_pages turns out to have been a coincidence since we had been working
withhuge_pages. 

Postgres happened to crash close enough to trying the huge_pages and did not appear to crash when they were disabled
ledus to make that conclusion. 

After a bit more careful testing we found out that postgres did indeed crash even without huge_pages.  The setting in
thelink appears to have resolved this issue. 

Thanks.

reiner

--On 12. April 2016 13:20:10 -0700 Andres Freund <andres@anarazel.de> wrote:

>> When working with huge_pages, we initially got this error.
>> 
>> munmap(0x3efbe4000000) failed: Invalid argument
> 
> *munmap*, not mmap failed? that's odd; because there the hugepagesize
> shouldn't have much of an influence. If something fails it should be the
> initial mmap.  Could you show a strace of a failed start with an
> unmodified postgres?

Well, the manpage on the the buildfarm member chub says this:

<snip>
The address addr must be a multiple of the page size.  All pages containing
a part of the indicated range are unmapped,  and      subsequent  references to these pages will generate SIGSEGV.  It
is
not an error if the indicated range does not contain any      mapped pages.
</snip>

There are other production machines running on this POWER8 machine, all
have huge pages activated and i've seen this message several times, but
afair only during initdb and when stopping the server. No crashes. 

Indeed, I had the exactly same patch than Reiner, when investigating this,
but i couldn't find an easy way to make it somehow automatic for other page
sizes (e.g. on large Intel machines you can have even 1G Pages).

Though, we haven't encountered any problems on the production machines so
far.

-- 
Thanks
Bernd

On 2016-04-14 12:05:39 +0200, Bernd Helmle wrote:
> 
> 
> --On 12. April 2016 13:20:10 -0700 Andres Freund <andres@anarazel.de> wrote:
> 
> >> When working with huge_pages, we initially got this error.
> >> 
> >> munmap(0x3efbe4000000) failed: Invalid argument
> > 
> > *munmap*, not mmap failed? that's odd; because there the hugepagesize
> > shouldn't have much of an influence. If something fails it should be the
> > initial mmap.  Could you show a strace of a failed start with an
> > unmodified postgres?
> 
> Well, the manpage on the the buildfarm member chub says this:
> 
> <snip>
> The address addr must be a multiple of the page size.  All pages containing
> a part of the indicated range are unmapped,  and
>        subsequent  references to these pages will generate SIGSEGV.  It is
> not an error if the indicated range does not contain any
>        mapped pages.
> </snip>

Uh, but that's something different, no? The address we pass to munmap()
is what mmap() returned. The page size bit is relevant if you want to
unmap part of a mapped region.


> Though, we haven't encountered any problems on the production machines so
> far.

That's after applying some patch to pad to a larger size?

Greetings,

Andres Freund