本篇為Redis性能問題診斷系列的第四篇，也是最後一篇，主要從應用程式、系統、伺服器硬體及網路系統等層面上進行講解，重點分享了哪些配置需要重點關註和調整優化，才能最大程度的發揮Redis的處理能力； ...
（本文首發於“資料庫架構師”公號，訂閱“資料庫架構師”公號，一起學習資料庫技術，助力職業發展） 本篇為Redis性能問題診斷系列的第四篇，也是最後一篇，主要從應用程式、系統、伺服器硬體及網路系統等層面上進行講解，重點分享了哪些配置需要重點關註和調整優化，才能最大程度的發揮Redis的處理能力；
一、伺服器預留足夠記憶體，監控SWAP使用
Swap是操作系統層面行為，指當伺服器記憶體不足時，會將原本在記憶體中的一部分數據拿出放入磁碟，如果再次訪問這部分數據就會響應很慢，因為磁碟的訪問速度是遠遠不如記憶體的。
Redis作為記憶體資料庫，有個常識一定要記住：所有的數據預設都是在記憶體中，不存在一部分在記憶體一部分在磁碟中的情況，除非被迫發生了SWAP。
說明：Redis在2.6版本之前有個VM【虛擬記憶體】特性，可以支持數據存放在記憶體和磁碟中，不過帶來的性能波動影響太大，就被廢棄了。但現在網上還有不少人在傳抄相關VM特性的文章，太有誤導性！
官方VM廢棄說明：https://redis.io/docs/reference/internals/internals-vm/
可以通過以下方式來查看 Redis 進程是否使用到了 Swap：
1.獲取redis對應的進程id
shell> redis-cli info | grep process_id
2.查看 Swap 使用情況
shell>cat /proc/$pid/smaps | egrep '^(Swap|Size)'
輸出結果如下：
Size: 1492 kB
Swap: 0 kB
Size: 32 kB
Swap: 0 kB
Size: 2196 kB
Swap: 0 kB
Size: 2048 kB
Swap: 0 kB
Size: 4 kB
Swap: 0 kB
Size: 1576 kB
上圖中size代表Redis進程占用的一塊記憶體空間大小，並對應一個Swap。
Swap後的數字表示該記憶體空間有多少已經被換到磁碟上了，如果兩者相等，則代表這塊記憶體空間的數據全都被換到了上了。
針對使用swap的解決方案可以參考如下：
a.提高Redis所在伺服器的記憶體並預留可用記憶體，建議剩餘可用記憶體至少保留20%以上；
b.Redis單獨部署或降低單機部署實例數量，不和其他應用程式混合部署，避免多服務爭用記憶體導致Redis數據被swap到磁碟上。
平時對Redis所在伺服器的剩餘可用記憶體及Swap 使用情況進行監控，在記憶體不足或使用到 Swap 時報警出來，及時干預處理。
二、.使用萬兆網卡，避免網路帶寬打滿
Redis 的高性能，除了數據都在記憶體之外，就在於網路 IO 了，如果網路存在瓶頸，那麼也會嚴重影響 Redis 的性能。
網路帶寬過載的情況下，比如帶寬被打滿，那麼伺服器在 TCP 層和網路層就會出現數據包發送延遲、丟包等情況。
如果確實出現這種情況，我們需要及時核對原因，主要有以下幾個：
a.某個Redis服務訪問量過大，可能QPS高疊加操作的Key過大，導致網路滿載；
b.所在伺服器網卡上限過小，如千兆網卡或者虛擬機限速200MB等；
c.伺服器網卡/網線/驅動等問題，導致萬兆的網卡降頻為千兆或者被限流。
查看網卡速度：ethtool eth0
針對網路過載可以採用以下方案來解決：
a.降低單機部署Redis實例個數，打散重度使用網路帶寬的Redis服務到多台伺服器；
b.對Redis服務使用的網路帶寬進行監控，可以關註性能指標：instantaneous_input_kbps、instantaneous_output_kbps
c.使用萬兆網卡的伺服器，並添加對帶寬上限【警惕網卡從萬兆降為千兆】、網路帶寬使用、丟包情況的監控；
d.遵守Redis使用規範，比如控制寫入Redis中的VALUE大小、限制使用smembers或hgetall等操作的集合成員個數等。
三、根據場景選擇是否使用SSD磁碟
大家要根據自己的實際場景判斷，比如使用單節點且用於緩存服務的情形，就不需要使用SSD磁碟。
但是如果希望使用Redis的持久化能力來保證數據安全，那麼磁碟IO能力就不得不重視了。
這裡對於Redis的持久化不做詳細介紹，具體可以參考上篇文章。
Redis中對IO比較敏感的操作主要有下麵幾類：
a.AOF持久化，相關磁碟操作有： AOF命令落盤、AOF文件重寫；
b.RDB持久化，相關磁碟操作有：主從複製主節點RDB生成快照、從節點載入RDB文件、備份觸發RDB快照、配置觸發自動RDB快照
上面列出的都會嚴重依賴磁碟IO能力，特別是單機部署多Redis實例的情況，如果磁碟IO能力一般，那麼就會嚴重影響Redis的性能。
四、系統參數配置
1.記憶體分配策略參數vm.overcommit_memory
Redis啟動給出Warning提示：
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.
這裡首先解答下什麼是Overcommit？
Linux對大部分申請記憶體的請求都回覆"yes"，以便能跑更多更大占用記憶體的程式。因為申請記憶體後，並不會馬上使用記憶體。這種技術叫做Overcommit。
當linux發現記憶體不足時，會發生OOM killer(OOM=out-of-memory)。它會選擇殺死一些進程(用戶態進程，不是內核線程)，以便釋放記憶體。
overcommit_memory的幾個主要值的說明：
0:表⽰內核將檢查是否有⾜夠的可⽤記憶體供應⽤進程使⽤；如果有⾜夠的可⽤記憶體，記憶體申請允許；否則，記憶體申請失敗，並把錯誤返回給應⽤進程；
1: 表⽰內核允許分配所有的物理記憶體，⽽不管當前的記憶體狀態如何；
2: 表⽰內核允許分配超過所有物理記憶體和交換空間總和的記憶體。
這裡建議調整為1，相關調整方式：
永久生效：
編輯vim /etc/sysctl.conf ，改vm.overcommit_memory=1，然後sysctl -p 使配置文件生效
臨時生效：
echo 1 > /proc/sys/vm/overcommit_memory
上述日誌中的Background save代表的是bgsave和bgrewriteaof， 如果當前可用記憶體不足， 操作系統應該如何處理fork操作呢？
如果vm.overcommit_memory=0， 代表如果沒有可用記憶體， 就申請記憶體失敗， 對應到Redis就是執行fork失敗， 在Redis的日誌會出現：
Cannot allocate memory
Redis建議把這個值設置為1， 是為了讓fork操作能夠在低記憶體下也執行成功。
2.操作系統記憶體大頁參數配置
Redis啟動給出Warning提示：
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.
意思是：你的Redis所在伺服器當前使用的是記憶體大頁機制，可能導致Redis訪問延遲和記憶體使用問題。
那什麼是記憶體大頁呢？
應用程式向操作系統申請記憶體空間時，是按記憶體頁為單位進行申請的，預設大小是4KB。不過Linux從 2.6.38內核版本開始，支持了記憶體大頁機制，可以允許向操作系統一次申請 2MB 大小的記憶體。由於申請的記憶體單位變大，也意味著申請耗時相對變長。
那對於 Redis服務會有什麼影響呢？
當 Redis 在執行後臺 RDB 和 AOF rewrite 時，採用 fork 子進程的方式來處理。但主進程 fork 子進程後，此時的主進程依舊是可以接收寫請求的，而進來的寫請求，會採用 Copy On Write（寫時複製）的方式操作記憶體數據。
也就是說，主進程一旦有數據需要修改，Redis 並不會直接修改現有記憶體中的數據，而是先將這塊記憶體數據拷貝出來，再修改這塊新記憶體的數據，這就是所謂的「寫時複製」。
寫時複製可以理解為：需要發生寫操作哪個Key，就需要先拷貝這個Key，然後再修改。
這裡註意，主進程在修改拷貝記憶體數據時，這個階段就涉及到新記憶體的申請。如果此時操作系統開啟了記憶體大頁，那麼在此期間，應用程式即便只修改 10B 的數據，Redis 在申請記憶體時也會以 2MB 為單位向操作系統申請，申請記憶體的耗時變長，進而導致每個寫請求的延遲增加，影響到 Redis 性能。
所以為了避免過多的記憶體申請，我們需要關閉記憶體大頁機制：
cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never
如果輸出選項是 always，就表示目前開啟了記憶體大頁機制，我們需要關掉它：
echo never > /sys/kernel/mm/transparent_hugepage/enabled
其實，操作系統提供的記憶體大頁機制，其優勢是可以在一定程式上降低應用程式申請記憶體的次數。
比如針對大數據、對象存儲相關的服務來說可能會更好，但是對於 Redis 這種對性能和延遲極其敏感的資料庫來說，我們希望 Redis 在每次申請記憶體時，耗時儘量短，建議關閉這個參數。
五、其他影響訪問Redis的性能的因素
1.應用程式配置不合理
a.應配置合理的連接數等相關參數，比如jedis，預設MaxActive最大連接數只有8個，在高QPS時就會出現無法獲取新連接的提示：
redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool … Caused by: java.util.NoSuchElementException: Timeout waiting for idle object at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:449)
b.驅動版本過低。低版本的Driver連接高版本Redis，除了無法使用最新的特性外，還會經常出現連接不釋放、記憶體泄露、訪問緩慢等問題。
2.使用連接池，避免使用短連接模式.特別是使用PHP的應用，頻繁的連接創建與銷毀，在高QPS訪問時網路開銷巨大；
3.CPU綁核及主頻影響
Redis是單線程模型處理處理用戶需求，那麼處理的吞吐、效率就會極度依賴CPU的處理能力，所以選型CPU時，如果部署的Redis平時QPS較高，可以採購主頻高些的CPU.
另外現在的CPU都是多核處理，為了提高服務性能，降低應用程式在多個 CPU 核心之間的上下文切換帶來的性能損耗，通常採用的方案是進程綁定 CPU 的方式提高性能。
但是Redis的綁核操作過於複雜，對於單機多實例的管理挑戰過高，再加上Redis 的性能已經足夠優秀，不建議綁定 CPU來處理，這裡也不做深入說明。
最後總結：
本篇為Redis性能診斷的完結篇，通過總結常見的可能導致訪問響應延遲、甚至阻塞的問題的各種場景，以及如何定位及分析針對性地提供瞭解決方案。
但是由於篇幅限制，關於 Redis 的很多細節也無法全部展開，後續也會對Redis使用的各種技巧、架構及內部的工作原理深入分享，歡迎保持關註。
如果這篇文章對你有幫助，還請幫忙點贊、在看、轉發 一下，你的支持會激勵我們輸出更多高質量的文章，非常感謝！
如果你還想看更多優質文章，歡迎關註我的公眾號「資料庫架構師」，提升資料庫技能。
