memory errors on startup in postgresql 9.6 log - MAP_HUGETLB failed

On postgresql startup, I see this in the log files


2017-07-17 05:21:01.743 UTC > LOCATION: CreateAnonymousSegment, pg_shmem.c:484

2017-07-17 05:21:01.868 UTC > LOG: 00000: redirecting log output to logging collector process

2017-07-17 05:21:01.868 UTC > HINT: Future log output will appear in directory "pg_log".

2017-07-17 05:21:01.868 UTC > LOCATION: SysLogger_Start, syslogger.c:622

2017-07-21 05:46:01.680 UTC > DEBUG: 00000: logger shutting down

2017-07-21 05:46:01.680 UTC > LOCATION: SysLoggerMain, syslogger.c:490

2017-07-21 05:46:01.973 UTC > DEBUG: 00000: mmap(8264876032) with MAP_HUGETLB failed, huge pages disabled: Cannot allocate memory

I have never used huge pages - turning on huge_pages in postgres.conf does not help, I get different errors and the server will not start. I am unfamiliar with these settings.

Please help point me in the right direction to explore why these errors are occurring and what I should do about them - adjustments to memory settings, logging (it is set very high) vacuuming, or what?

What parts of the PostgreSQL manual are relevant?

Stack: postgresql 9.6 on aws ec2 generic linux

UPDATE: This post was originally written about things I noticed on installing a backup utility, and how that appeared to be causing errors, then I noticed a server without the utility is logging the same messages.

Met the same issue when deploying postgre-sql by postgres-operator (https://github.com/zalando/postgres-operator) in Kubernetes. The size of required shared memory usage by postgre-sql is based on shared_buffers and max_connections. While, the shared_buffers configured by patroni is calculated based on the size of physical memory in the host. In our case, the size of physical memory is huge, however the memory limit of the container of postgre-sql is configured much less than the size of physical memory in the host. As a result, postgre-sql tries to allocate 4GB memory however only 256MB is available, and then fail to start.

Specify shared_buffers with a reasonable value resolved the problem.

StackExchange Database Administrators Q#184951, answer score: 3