Redis性能篇(二)CPU核和NUMA架构的影响

时间:2024-01-27 21:43:57

Redis被广泛使用的一个很重要的原因是它的高性能。因此我们必要要重视所有可能影响Redis性能的因素、机制以及应对方案。影响Redis性能的五大方面的潜在因素,分别是:

这一讲,我们来学习一下CPU对Redis的性能影响及应对方法。

主流CPU架构

学习之前,我们先来了解主流CPU架构有哪些,有什么特点,以便我们更好地了解CPU是如何影响Redis的。

CPU多核架构

CPU多核架构

  • 一个CPU处理器中一般有多个运行核心,称为物理核。
  • 物理核包括私有的一级指令/数据缓存(L1缓存)和二级缓存(L2缓存)。
  • 每个物理核会运行两个超线程,也叫作逻辑核。同一个物理核的逻辑核会共享使用L1、L2缓存。
  • 不同的物理核共享三级缓存(L3缓存)

多CPU Socket架构

多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访问内存,这个过程会花费较多时间。

image

为了避免Redis跨CPU Socket访问网络数据,我们最好把网络中断程序和Redis实例绑在同一个CPU Socket上,这样一来,Redis实例就可以直接从本地内存读取网络数据了。

image

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核上。

参考资料