Redis性能篇（二）CPU核和NUMA架構的影響

Redis被普遍使用的一個很重要的緣由是它的高性能。所以咱們必要要重視全部可能影響Redis性能的因素、機制以及應對方案。影響Redis性能的五大方面的潛在因素，分別是：

• Redis內部的阻塞式操做
• CPU核和NUMA架構的影響
• Redis關鍵系統配置
• Redis內存碎片
• Redis緩衝區

這一講，咱們來學習一下CPU對Redis的性能影響及應對方法。

主流CPU架構

學習以前，咱們先來了解主流CPU架構有哪些，有什麼特色，以便咱們更好地瞭解CPU是如何影響Redis的。

CPU多核架構

• 一個CPU處理器中通常有多個運行核心，稱爲物理核。
• 物理核包括私有的一級指令/數據緩存（L1緩存）和二級緩存（L2緩存）。
• 每一個物理核會運行兩個超線程，也叫做邏輯核。同一個物理核的邏輯核會共享使用L一、L2緩存。
• 不一樣的物理核共享三級緩存（L3緩存）

多CPU Socket架構

在多CPU架構上，應用程序能夠在不一樣的處理器上運行。

應用程序在不一樣的Socket間調度運行時，訪問以前的Socket的內存，這種訪問屬於遠端內存訪問。

和訪問Socket直接鏈接的內存相比，遠端內存訪問會增長應用程序的延遲。

把這個架構稱爲非統一內存訪問架構（Non-Uniform Memory Access，NUMA架構）。

CPU多核對Redis性能的影響

若是在CPU多核場景下，Redis實例被頻繁調度到不一樣CPU核上運行的話，那麼，對Redis實例的請求處理時間影響就更大了。每調度一次，一些請求就會受到運行時信息、指令和數據從新加載過程的影響，這就會致使某些請求的延遲明顯高於其餘請求。

要避免Redis老是在不一樣CPU核上來回調度執行。最直接的方法是把Redis實例和CPU核綁定了，讓一個Redis實例固定運行在一個CPU核上。

經過taskset命令進行綁核：

taskset -c 0 ./redis-server

綁核不只對下降尾延遲有好處，一樣也能下降平均延遲、提高吞吐率，進而提高Redis性能。

CPU的NUMA架構對Redis性能的影響

在實際應用Redis時，有一種作法：爲了提高Redis的網絡性能，把操做系統的網絡中斷處理程序和CPU核綁定。

在CPU的NUMA架構下，當網絡中斷處理程序、Redis實例分別和CPU核綁定後，就會有一個潛在的風險：若是網絡中斷處理程序和Redis實例各自所綁的CPU核不在同一個CPU Socket上，那麼，Redis實例讀取網絡數據時，就須要跨CPU Socket訪問內存，這個過程會花費較多時間。

爲了不Redis跨CPU Socket訪問網絡數據，咱們最好把網絡中斷程序和Redis實例綁在同一個CPU Socket上，這樣一來，Redis實例就能夠直接從本地內存讀取網絡數據了。

CPU的NUMA架構下進行綁定要注意CPU核的編號規則，能夠執行lscpu命令來查看核的編號。

lscpu

Architecture: x86_64
...
NUMA node0 CPU(s): 0-5,12-17
NUMA node1 CPU(s): 6-11,18-23
...

 

不過，凡事都有兩面性，綁核也存在必定的風險。接下來就來了解下它的潛在風險點和解決方案。

綁核的風險和解決方案

方案一：一個Redis實例對應綁一個物理核

在給Redis實例綁核時，咱們不要把一個實例和一個邏輯核綁定，而要和一個物理核綁定，也就是說，把一個物理核的2個邏輯核都用上。

方案二：優化Redis源碼

經過修改Redis源碼，把子進程和後臺線程綁到不一樣的CPU核上。

參考資料

• 17 | 爲何CPU結構也會影響Redis的性能？