Discourse_docker redis overcommit_memory

docker

(John Devura) #1

discourse docker image spouts out some error when creating.

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

is it a problem or does it not matter?


(Jeff Atwood) #2

I believe @sam once said

redis was chucking an error causing a 500 on bgsave despite having a gig and a half of free ram.

It needed this overcommit flag on the kernel, I will be amending ./launcher to add a pre-req test for this setting cause it a rather bad failure mode for no legit reason.

Which is described thusly at http://redis.io/topics/faq

Background saving is failing with a fork() error under Linux even if I’ve a lot of free RAM!

Short answer: echo 1 > /proc/sys/vm/overcommit_memory :slight_smile:

And now the long one:

0: heuristic overcommit (this is the default)
1: always overcommit, never check

Redis background saving schema relies on the copy-on-write semantic of fork in modern operating systems: Redis forks (creates a child process) that is an exact copy of the parent. The child process dumps the DB on disk and finally exits. In theory the child should use as much memory as the parent being a copy, but actually thanks to the copy-on-write semantic implemented by most modern operating systems the parent and child process will share the common memory pages. A page will be duplicated only when it changes in the child or in the parent. Since in theory all the pages may change while the child process is saving, Linux can’t tell in advance how much memory the child will take, so if the overcommit_memory setting is set to zero fork will fail unless there is as much free RAM as required to really duplicate all the parent memory pages, with the result that if you have a Redis dataset of 3 GB and just 2 GB of free memory it will fail.

Setting overcommit_memory to 1 says Linux to relax and perform the fork in a more optimistic allocation fashion, and this is indeed what you want for Redis.

It generally won’t be an issue unless your Discourse is quite massive and thus Redis is storing a super huge number of key/value pairs, but we should fix it up.

(also it would be nice to not see that warning all the time, and get questions about it…)


(Jeff Atwood) #3

@sam did we ever get this added to /launcher? If not can you take this @tgxworld?


(Sam Saffron) #4

not in launcher, as a pre-req, its more of a pre-req in the redis template, I don’t need this blocking the general installation.

Additionally we should simply allow redis to keep working if it fails to save


(Allen - Watchman Monitoring) #5

I’m still seeing this on a rebuild… and the timing keeps these rather dire messages on screen for a while.

WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
Server started, Redis version 3.0.6
WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.

Of course, I’m not seeing any related issues, but I wonder if there is a way address or quash the warnings?


(Sam Saffron) #6

Have you tried?

To fix this issue add ‘vm.overcommit_memory = 1’ to /etc/sysctl.conf and then reboot


(Allen - Watchman Monitoring) #7

I had no idea a change could be made to my host… I assumed that would have to be done within the docker image.

Edit: relevant discussion -