I have windows 10 home, where is installed Ubuntu

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.2 LTS
Release:        18.04
Codename:       bionic

I have installed Redis 5.0.5 (it mostly with make and make install)

When I startup the server with redis-server it shows some warnings.

I have removed one about overcommit_memory

But about:

WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.

I have read these two links:

Thus both indicate do the following:

  • Go to the /etc directory
  • Create the rc.local file, sudo vim rc.local
  • Add the sysctl -w net.core.somaxconn=65535 content and save

I can confirm through

cat rc.local
sysctl -w net.core.somaxconn=65535

Well in a secondary terminal I execute redis-cli shutdown and in the primary terminal execute again redis-server

Problem the same warning appears, What is missing?

Note I have the same situation even after to execute sudo chmod +x rc.local

Comment From: emeric-martineau

Hi,

have you try to echo 1024 > /proc/sys/net/core/somaxconn with root user and restart Redis ?

If works, you can add net.core.somaxconn=65535 in the /etc/sysctl.conf file and restart ?

Regards,

Comment From: manueljordan

Please give some days to accomplish this, I deleted the Ubuntu (Cannonical) Windows integration and moved to VirtualBox with Ubuntu.

Thanks for the feedback

Comment From: mutecamel

In my case, this solves the problem. Thanks @bubulemaster

Comment From: rafaeldev

I only can do edit somaxconn value with this command: sysctl -w net.core.somaxconn=512

Comment From: DMTSource

I am also getting these redis related errors on a manual cluster setup and found these useful instructions for updating maximum open files, socket max connections, memory overcommit, and transparent huge pages for redis for older, or bare metal linux(ubuntu 1404 in my case) os and beyond: https://stackoverflow.com/a/46255542/927972

Comment From: LaOwlLol

have you try to echo 1024 > /proc/sys/net/core/somaxconn with root user and restart Redis ?

If works, you can add net.core.somaxconn=65535 in the /etc/sysctl.conf file and restart ?

I've tried this. The first command did not produce any error, but modifying /etc/sysctl.conf did not make the change stick after rebooting.

lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.5 LTS Release: 18.04 Codename: bionic

Any other suggestions?

Comment From: yossigo

@LaOwlLol I assume you're also using Windows System for Linux, is that correct?

If so, please note that there's a big difference between WSL1 which only provides a user-space environment and WSL2 which is a fully virtualized environment running a Linux kernel. Since WSL1 is not a real Linux environment most of the kernel-related tunings simply don't work.

Comment From: manueljordan

I am agree with @yossigo ... I had the same situation about wrong behaviour with Mysql, install Ubuntu on Windows (through the latter itself) makes no available to have neither a true installation nor functional execution for some software, in my case for MySQL and Redis.

So, if you can use VirtualBox with Ubuntu do it, or have your real installation. All the features and software of the OS itself are available to let run any server in peace and totally functional. In this case for MySQL, I didn't test Redis with the settings suggested.

Comment From: yossigo

@manueljordan Please note that WSL 2.0 is actually a VM (like VirtualBox) and may solve these issues as well.

Comment From: manueljordan

@yossigo - understood, please remember I had this issue on 2019, so I moved to VirtualBox directly since then. If WSL 2.0 does what you did indicate, sounds great. But to be honest I prefer have Ubuntu 100% available with all its features.

Comment From: LaOwlLol

@LaOwlLol I assume you're also using Windows System for Linux, is that correct?

I'm actually running the Ubuntu VM on a FreeNAS (FreeBSD derivative now called TrueNas) machine. I run Redis in a docker container on that VM.

I apologize if this is veering off topic, but I'm not super familiar with kernel virtualization or system administration.

I read that these settings, somaxconn and transparent_hugepage before that, had to be modified on the host and not the container. I assume 'the host' referred to the VM; host to the container. I was not thinking about the FreeNAS (the host's host XD) kernel.

When I set THP to disabled a restart of the VM was not required. I just brought the container down and back up (with docker-compose). This did not appear to be the case for somaxconn, and as I initially posted modifying /etc/sysctl.conf did not make the setting change stick after reboot. Also on rebooting the VM I lost the modification to THP.

docker redis issue #55 and the related issues had a number of suggestion for setting these values on system startup. Always being cautious about modifying the boot config files, I was waiting for a weekly snapshot before modifying my systemd. There was also a suggestion some where to set the values (THP enable and defrag) in /etc/rc.local.

Apologies for the long post.

Does bhyve have the same user-space limitations when kernel tuning (should modifying at the VM level work or will it have to be done at freeNAS kernel)? Would systemd or rc.local be an alternative place to modify somaxconn?

I appreciate all the help. I run this Redis instance for a hobby project so apologies once again for reviving an some what stale/resolved issue. However it would be nice to find an automatic set and forget solution for my project.

Comment From: yossigo

@LaOwlLol THP is a global kernel parameter, so modifying it from a container (if the container is privileged to do so) affects the entire system. If you don't persist it in sysctl.conf it will not survive a restart. somaxconn on the other hand is maintained per network namespace (which maps to a container), so changing it will not affect the entire system and will not survive container restart - and you should set it up inside the container when starting.

I'm closing this issue as I believe it already answers the original question.

Comment From: nicholaswmin

Make sure you don't have a phantom Redis instance running on the port.

$ lsof -i -P -n | grep LISTEN

if you do, just grab it's pid and tell it to take a hike:

# SIGTERM for politeness
$ kill <pid>