Transparent Huge Pages support should be disabled

[phpguru]

I am running Docker on a latest-gen Mac OS X laptop with 32GB of RAM, 6.0GB allocated to Docker. I have a Dockerfile that is simply copying a file with our custom config:

FROM: redis:latest
CMD [ "redis-server", "/usr/local/etc/redis/redis.conf" ]

I then use a mounted volume, and grab the latest snapshot redis dump.rdb file from one of our production machines, place it in the mount, then start up redis. This had been working fine, until recently, the dump file is now 1.9GB and upon running the container, it hangs for awhile, clients get

LOADING Redis is loading the dataset in memory

and then after maybe 2-3 minutes of fan spinning, we get

Connection refused [tcp://redis:6379]

At this point the Redis container is exited. Running docker logs redis gives:

1:M 30 Apr 2019 17:49:11.527 # 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.

Is this something that you can update in the Docker image? Or a Mac OS X (host) thing? Or is the error a false positive?

[wglambert]

See #55 (comment), #19, and #35

You might also like this comment in particular #55 (comment)

[phpguru]

@wglambert Ah, so this is a Docker Mac VM thing, got it, I should've searched the closed comments.

[sanjibukai]

Hi everybody,

Just to understand..
Today I faced the following errors for the first time (I don't know if they were here form the beginning but I only noticed them today..)

oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
# Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=1, just started
# Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
* Running mode=standalone, port=6379.
# 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 initialized
# 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.
* DB loaded from disk: 0.004 seconds
* Ready to accept connections

So I have 3 warnings (besides the lack of the config file) related to:

1. the TCP backlog
2. the overcommit memory
3. the Transparent Hub Pages (THP)

Finally I was able to fix those warning with the following actions (read from various GH issues):

1. Adding the following in the compose file:

redis:
  ...
  sysctls:
    net.core.somaxconn: "65535"

2. Adding the following line to the file /etc/sysctl.conf (in the host ):
   vm.overcommit_memory = 1

3. Running in the host (not in the docker container) the following lines:
   echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

But I wanted to be sure.. I saw GH issues referring to them as if there are all related but it doesn't seem so..

Do these fixes are the right ones, or are they only some workarounds?

Regarding the issue 2. since it is also related to sysctl is it possible to set that value in the docker-compose file as well (like 1.)

Regarding 3. since I saw some people running these commands in the container (if I'm not mistaken) so could it be possible to somehow embed those fixes in the image (docker-compose or a dockerfile).

Thank you very much.
I didn't want to open a new fix for something

[sc0ttwad3]

@sanjibukai The best solution I've found for 1), and 2) is to simply set them in the compose file:

redis:

    sysctls:
    - net.core.somaxconn=511
    - vm.overcommit_memory=1

and it's my understanding that handling 3) in some way, would require running the container as privileged, giving it access to the host, which isn't the best security idea.

Note: I would hesitate to follow net.core.somaxconn=65535 as the value—far above the 511 Redis wants—without understanding the implications (How TCP Backlog Works in Linux)