Warning Information solution after Redis is started

Warning Information solution after Redis is started

Solutions for Redis-related problems.

1st cases: after we started the Redis server, we will see three warnings. If we didn't see them, it would be good, but I did. If you see it, you cannot ignore it, so you can solve it well. I have sent these three warning messages, so you can feel them more directly. The effect is as follows:

1) The first warning message indicates that the TCP backlog setting of 511 cannot be enforced because/proc/sys/net/core/somaxconn is set to The lower value of 128

2) The second WARNING message prompts: 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.

The solution to these two problems is very simple, and there are similar solutions at night.

Solution:

// Modify the/etc/sysctl. conf file to solve these two problems. Add the following two sentences at the end of the file:

Net. core. somaxconn = 1024
Vm. overcommit_memory = 1

3) The third WARNING message prompts: 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.

This problem is not easy to solve. It takes a long time for me to solve it, so it must be recorded. Otherwise, it is not easy to look at it later.

You want to know more, you can view the blog http://docs.Fedoraproject.org/en-US/Fedora/21/html/System_Administrators_Guide/sec-GRUB_2_over_Serial_Console.html#sec-Configuring_GRUB_2.

Method 1:

Let's start to solve the third problem. If you are a grub2 linux system, take the following steps to close the Large Memory Page.

Step 1. edit/etc/default/grub and add the option transparent_hugepage = never in GRUB_CMDLINE_LINUX.

GRUB_TIMEOUT = 5
GRUB_DISTRIBUTOR = "$ (sed's, release. * $, G'/etc/system-release )"
GRUB_DEFAULT = saved
GRUB_DISABLE_SUBMENU = true
GRUB_TERMINAL_OUTPUT = "console"
GRUB_CMDLINE_LINUX = "rd. lvm. lv = fedora/swap rd. lvm. lv = fedora/root rhgb quiet transparent_hugepage = never"
GRUB_DISABLE_RECOVERY = "true"

Step 2. regenerate the grub configuration file

[Root @ linux ~] # Grub2-mkconfig-o/boot/grub2/grub. cfg

Step 3. Restart your system

This is a big success. If you are using grub, write the options to the grub. conf file.

Step 4. query hugepage status

[Root @ linux ~] # Cat/sys/kernel/mm/transparent_hugepage/enabled
Always madvise [never]

Method 2:

[Root @ linux ~] $ Grep Huge/proc/meminfo
AnonHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB

I am very happy to solve the problem. In fact, the three warning messages have provided a solution, some are temporary methods, some are permanent methods, but the third warning is not so straightforward.

2nd cases: Solve Sentinel warning when Redis starts

Solution to warning when Redis 3.0.7 is started

7283: M 12 Mar 12:13:33. 749 # WARNING: The TCP backlog setting of 511 cannot be enforced because/proc/sys/net/core/somaxconn is set to the lower value of 128.
7283: M 12 Mar 12:13:33. 749 # Server started, Redis version 3.0.7
7283: M 12 Mar 12:13:33. 749 # 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.
7283: M 12 Mar 12:13:33. 749 * The server is now ready to accept connections on port 6379

1st warnings (WARNING: The TCP backlog setting of 511 ......) Solution
Method 1: the temporary settings take effect: sysctl-w net. core. somaxconn = 1024
Method 2: Permanently effective: Modify the/etc/sysctl. conf file and add a line
Net. core. somaxconn = 1024
Then execute the command
Sysctl-p

Supplement:
Net. core. somaxconn is a kernel parameter in linux, indicating the upper limit of the backlog of the socket listener (listen.
Backlog is the socket listening queue. When a request is not processed or created, it enters the backlog.
The socket server can process all the requests in the backlog at one time, and the processed requests are no longer in the listening queue.
When the server processes Requests slowly, so that the listening queue is filled up, new requests will be rejected.
Therefore, net. core. somaxconn limits the size of the listener queue for receiving new TCP connections.
For a high-load web service environment that often processes new connections, the default 128 is too small. In most environments, we recommend that you increase the value to 1024 or more.

2nd warnings (WARNING overcommit_memory is set to 0! ...) There are also two solutions.
Method 1: the temporary settings take effect: sysctl-w vm. overcommit_memory = 1
Method 2: Permanently effective: Modify the/etc/sysctl. conf file and add a line
Vm. overcommit_memory = 1
Then execute the command
Sysctl-p

Supplement:
Overcommit_memory parameter description:
Set the Memory Allocation Policy (optional, based on the actual situation of the server)
/Proc/sys/vm/overcommit_memory
Optional values: 0, 1, and 2.
0 indicates that the kernel will check whether there is enough available memory for use by the process. If there is enough available memory, the memory application will be allowed; otherwise, the memory application will fail, and return the error to the application process.
1 indicates that the kernel allows all physical memory allocation regardless of the current memory status.
2. indicates that the kernel is allowed to allocate more memory than the total physical memory and swap space.
Note: When redis dumps data, it will fork a sub-process. Theoretically, the child process occupies the same memory as the parent, for example, the parent occupies 8 GB of memory, at this time, 8 GB of memory should also be allocated to the child. If the memory is not enough, it will often cause the redis server to go down or the IO load is too high, and the efficiency is reduced. Therefore, the optimized memory allocation policy should be set to 1 (indicating that the kernel allows allocation of all physical memory, regardless of the current memory status ).

Https://www.bkjia.com/Linux/2018-02/150957.htm