1、獲取redis-4.0.0源代碼
[thomaschen@localhost Downloads]$ curl -o redis-4.0.0.tar.gz http://download.redis.io/releases/redis-4.0.0.tar.gz
2、解壓源代碼
[thomaschen@localhost Downloads]$ tar -zxvf redis-4.0.0.tar.gz
3、編譯和安裝redis
[thomaschen@localhost Downloads]$ su Password: [root@localhost Downloads]$cd redis-4.0.0 & make [root@localhost redis-4.0.0]# cd src && make install PREFIX=/usr/local/redis
4. 復制默認配置文件
[root@localhost redis-4.0.0]# mkdir -p /usr/local/redis/conf [root@localhost redis-4.0.0]# cp redis.conf /usr/local/redis/conf
5. 啟動redis
[root@localhost redis-4.0.0]# cd /usr/local/redis [root@localhost redis]# bin/redis-server ./conf/redis.conf 12708:C 19 Jul 02:37:37.935 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 12708:C 19 Jul 02:37:37.935 # Redis version=4.0.0, bits=64, commit=00000000, modified=0, pid=12708, just started 12708:C 19 Jul 02:37:37.935 # Configuration loaded 12708:M 19 Jul 02:37:37.936 * Increased maximum number of open files to 10032 (it was originally set to 1024). _._ _.-``__ ''-._ _.-`` `. `_. ''-._ Redis 4.0.0 (00000000/0) 64 bit .-`` .-```. ```\/ _.,_ ''-._ ( ' , .-` | `, ) Running in standalone mode |`-._`-...-` __...-.``-._|'` _.-'| Port: 6379 | `-._ `._ / _.-' | PID: 12708 `-._ `-._ `-./ _.-' _.-' |`-._`-._ `-.__.-' _.-'_.-'| | `-._`-._ _.-'_.-' | http://redis.io `-._ `-._`-.__.-'_.-' _.-' |`-._`-._ `-.__.-' _.-'_.-'| | `-._`-._ _.-'_.-' | `-._ `-._`-.__.-'_.-' _.-' `-._ `-.__.-' _.-' `-._ _.-' `-.__.-' 12708:M 19 Jul 02:37:37.938 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. 12708:M 19 Jul 02:37:37.938 # Server initialized 12708:M 19 Jul 02:37:37.938 # 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. 12708:M 19 Jul 02:37:37.938 # 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. 12708:M 19 Jul 02:37:37.938 * DB loaded from disk: 0.000 seconds 12708:M 19 Jul 02:37:37.938 * Ready to accept connections
5.WARNING FIX
從上面redis啟動之后的控制台打出的信息來看，有3條WARNING信息。他們分別如下：
5.1. WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
解決方式：
第一種：無需重啟系統即可生效；但重啟以后信息丟失 [root@localhost ~]# echo 511 >/proc/sys/net/core/somaxconn 第二種：即可生效，重啟不會丟失 1. 編輯/etc/sysctl.conf文件，在其后追加 net.core.somaxconn = 511 2. sysctl.conf生效 [root@localhost ~]# sysctl -p
原理：
對於一個TCP連接，Server與Client需要通過三次握手來建立網絡連接.當三次握手成功后, 我們可以看到端口的狀態由LISTEN轉變為ESTABLISHED,接着這條鏈路上就可以開始傳送數據了.每一個處於監聽(Listen)狀態的端口,都有自己的監聽隊列.監聽隊列的長度,與如下兩方面有關：一個是 somaxconn參數；另一個是使用該端口的程序中listen()函數.故而somaxconn會限制了接收新 TCP 連接偵聽隊列的大小。對於一個經常處理新連接的高負載 web服務環境來說，默認的 128 太小了。大多數環境這個值建議增加到 1024 或者更多。 服務進程會自己限制偵聽隊列的大小，常常在它們的配置文件中有設置隊列大小的選項。大的偵聽隊列對防止拒絕服務 DoS 攻擊也會有所幫助。
redis配置文件中有個參數，tcp-backlog默認值是511，而系統默認的somaxconn是128，所以redis啟動以后報出這個warnning
5.2. 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.
解決辦法：
第一種：無需重啟系統即可生效；但重啟以后信息丟失 [root@localhost ~]# echo 1 > /proc/sys/vm/overcommit_memory 第二種：即可生效，重啟不會丟失 1. 編輯/etc/sysctl.conf文件，在其后追加 vm.overcommit_memory=1 2. sysctl.conf生效 [root@localhost ~]# sysctl -p
原理
內核參數overcommit_memory 確定了內存分配策略，可選值為[0、1、2]
0： 表示內核將檢查是否有足夠的可用內存供應用進程使用；如果有足夠的可用內存，內存申請允許；否則，內存申請失敗，並把錯誤返回給應用進程。
1： 表示內核允許分配所有的物理內存，而不管當前的內存狀態如何。
2： 表示內核允許分配超過所有物理內存和交換空間總和的內存
進程通常調用malloc()函數來請求分配內存，Linux支持超量分配內存，以允許分配比可用RAM加上交換內存的請求。Linux對大部分申請內存的請求都回復"yes"，以便能跑更多更大的程序。因為申請內存后，並不會馬上使用內存。這種技術叫做Overcommit。當linux發現內存不足時，會發生OOM killer(OOM=out-of-memory)。它會選擇殺死一些進程(用戶態進程，不是內核線程)，以便釋放內存。當oom-killer發生時，linux會選擇殺死哪些進程？選擇進程的函數是oom_badness函數(在mm/oom_kill.c中)，該函數會計算每個進程的點數(0~1000)。點數越高，這個進程越有可能被殺死。每個進程的點數跟oom_score_adj有關，而且oom_score_adj可以被設置(-1000最低，1000最高)。
5.3. 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. 編輯/etc/rc.local，在最后新增如下內容： if test -f /sys/kernel/mm/transparent_hugepage/enabled; then echo never > /sys/kernel/mm/transparent_hugepage/enabled fi 2. 重新啟動系統 [root@localhost redis]# reboot 第二種方法：及時生效，重啟丟失 [root@localhost redis]# echo never > /sys/kernel/mm/transparent_hugepage/enabled
原理
正常來說，有兩種方式來增加內存，可以管理的內存大小：
1.增大硬件內存管理單元的大小。
2.增大page的大小。
第一個方法不是很現實，現代的硬件內存管理單元最多只支持數百到上千的page表記錄，並且，對於數百萬page表記錄的維護算法必將與目前的數百條記錄的維護算法大不相同才能保證性能，目前的解決辦法是，如果一個程序所需內存page數量超過了內存管理單元的處理大小，操作系統會采用軟件管理的內存管理單元，但這會使程序運行的速度變慢。
從redhat 6（centos，sl，ol）開始，操作系統開始支持 Huge Pages，也就是大頁。簡單來說， Huge Pages就是大小為2M到1GB的內存page，主要用於管理數千兆的內存，比如1GB的page對於1TB的內存來說是相對比較合適的。
THP（Transparent Huge Pages）是一個使管理Huge Pages自動化的抽象層。目前需要注意的是，由於實現方式問題，THP會造成內存鎖影響性能，尤其是在程序不是專門為大內內存頁開發的時候，簡單介紹如下：操作系統后台有一個叫做khugepaged的進程，它會一直掃描所有進程占用的內存，在可能的情況下會把4kpage交換為Huge Pages，在這個過程中，對於操作的內存的各種分配活動都需要各種內存鎖，直接影響程序的內存訪問性能，並且，這個過程對於應用是透明的，在應用層面不可控制,對於專門為4k page優化的程序來說，可能會造成隨機的性能下降現象。