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.

  • 1
    its a usual out of memory error. – Sahap Asci Sep 3 '17 at 21:02
  • What are the differences in configuration between the server that you cloned and the server you are restoring to? You need to be sure at the very least to use the same postgresql.conf and sysctl.conf. Since your data directory looks like it's on a RHEL/CentOS variant, you could reload it with sysctl -p. Given your error messages, it looks like you need to change the kern.ipc.shmmax to be greater than the number of bytes listed in your second error message, as noted in the Managing Kernel Resources section of the docs. – Kassandry Sep 4 '17 at 4:51
  • It turns out the MAP_HUGETLB errors are on the production server too - so it appears those are unrelated to barman. I am going to have to rewrite this post or delete it. – csdev Sep 4 '17 at 17:17
  • 1
    This question is rewritten without mentioning barman or replication - I think it might just be memory misconfiguration, or logging is up too high or something - I will begin exploring the kernel memory resources section – csdev Sep 4 '17 at 18:48
  • Which instance type are you using? What are the memory-related PostgreSQL settings? Is there any activity at the time of the problem, or is it really the startup? – dezso Sep 4 '17 at 20:15

Own experience suggests that this is due to PostgreSQL running out-of-memory.

For instance, I ran into this error when attempting to bump max_connections up to a very high value (say, 2000) on a "small" server.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.