How to fix the WARNINGs when running the redis:alpine Docker image

Question

If I run the redis:alpine Docker image using the commmand

docker run redis:alpine

I see several warnings:

1:C 08 May 08:29:32.308 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 3.2.8 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                   
 (    '      ,       .-`  | `,    )     Running in standalone mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 6379
 |    `-._   `._    /     _.-'    |     PID: 1
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

1:M 08 May 08:29:32.311 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
1:M 08 May 08:29:32.311 # Server started, Redis version 3.2.8
1:M 08 May 08:29:32.311 # 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.
1:M 08 May 08:29:32.311 # 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.
1:M 08 May 08:29:32.311 * The server is now ready to accept connections on port 6379

I've tried to fix the first two of these warnings using the following Dockerfile:

FROM redis:alpine
COPY somaxconn /proc/sys/net/core/somaxconn
COPY sysctl.conf /etc/sysctl.conf
CMD ["redis-server", "--appendonly", "yes"]

where my local file somaxconn contains the single entry 511 and sysctl.conf contains the line vm.overcommit_memory = 1. However, I still get the same warnings when I build and run the container.

How can I get rid of these warnings? (There is mention of the issues in https://www.techandme.se/performance-tips-for-redis-cache-server/ but the solution described there, involving modifying rc.local, seems to pertain to Rasperry Pi).

Answer 1

Bad way to handle things: /proc is read-only filesystem to modify it you can run Docker in privileged mode than you can modify it after the container was started.

If running the container in privileged mode, you can disable THP using these commands:

# echo never > /sys/kernel/mm/transparent_hugepage/enabled
# echo never > /sys/kernel/mm/transparent_hugepage/defrag

Proper way: Ensure that you run newer versions of Docker (upgrade if needed). run subcommand has the --sysctl option:

$ docker run -ti --sysctl net.core.somaxconn=4096 --rm redis:alpine /bin/sh
root@9e850908ddb7:/# sysctl net.core.somaxconn
net.core.somaxconn = 4096
...

Unfortunately: vm.overcommit_memory is currently not allowed to be set via --sysctl paramter the same applies to THP (transparent_hugepage), this is because they are not namespaced. Thus to fix these warning in a container running on a Linux Host you can change them directly on host. Here the related Issues:

• #19
• #55

You don't need privileged mode for the proper way approach.