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的性能？