CPU架构对redis性能的影响分析

目录

• 一、主流多核CPU
  • 1.1 多核CPU缓存结构
  • 1.2 对redis的影响
• 二、NUMA CPU
  • 2.1 UMA（SMP）架构VS NUMA 架构
  • 2.2 对redis的影响

本文主要基于cpu的架构和运行机制来分析cpu架构对redis的性能影响。

一、主流多核CPU

1.1 多核CPU缓存结构

访问速度

1. L1>L2>L3>内存。

权限

1. L1和L2为每个核私有（每一个物理核下面的逻辑核共享L1和L2）

2. L3缓存为多核共享

访问顺序

1. CPU访问时先从L1和L2缓存读取数据，没有会去L3缓存访问。
2. 当前核频繁执行的指令和数据会被存储在L1和L2缓存中，如果cpu每次执行都能从L1,L2缓存中读到数据，程序的性能会非常好，应该尽量提高L1和L2的缓存命中率。

context switch

线程在多个CPU之间轮换叫做context switch，在多核环境下，如果发生context switch：

1. Redis实例线程的运行环境从原有A核移动到了新的B核，那么首先上下文信息需要重新copy到新核。
2. 同时原有的L1和L2缓存的数据也失效了（私有），需要重新加载，这会影响程序的性能。【降低了L1，L2的命中率】

1.2 对redis的影响

Redis主操作虽然是单线程，自己不做线程调度，但是CPU本身可能会把这个主线程调度到不同的核上面，最终发生context switch，可以通过对redis实例进行绑核来解决这个问题，最终redis实例强制运行在一个cpu核上，从而彻底避免了context switch。

绑核产生的问题
redis实例除了主线程外还有其他额外的后台线程，子线程，如果设置了绑核，把redis实例榜单到了特定的核，这会导致子线程和主线程竞争同一个核，子线程有可能会导致主线程阻塞，最终也会影响redis的性能。
解决竞争

如果对redis实例绑核，有两个方法可以降低主子线程cpu的竞争

1. redis实例和物理核绑定，一个物理核有多个逻辑核，这样子线程和主线程共享多个逻辑核，一定程度上减少竞争。
2. 修改redis源码，将子线程绑定到其他核。

二、NUMA CPU

2.1 UMA（SMP）架构VS NUMA 架构

单核或者多核计算机上的 CPU 计算机中的所有资源都是共享的，这种架构被称作对称多处理器架构（Symmetric Multi-Processor、SMP），或者称为一致存储器访问结构（Uniform Memory Access、UMA）。

SMP随着核数量的增加，总线等会成为瓶颈。所有引入了多个CPU（多CPU Socket），NUMA（NON Uniform Memory Access）架构，NUMA节点包含独立的物理CPU和内存，CPU Socket访问本地内存和远程内存的开销是不一样的。

2.2 对redis的影响

通过之前的绑核，可以解决redis实例本身在不同cpu之间切换导致的context switch开销。

redis是基于网络部署的，内部采用了IO多路复用来实现（epoll机制）：

1. 网络中断处理程序用于检测IO数据是否到达
2. redis主线程用于最终的命令实现

为了避免网络中断处理程序和redis主线程竞争cpu，也为了避免网络中断处理程序在不同CPU上进行调度，一般会把网络中断处理程序也会和CPU核进行绑定，从而提升redis的性能。

通过上面的分析可以看出，网络中断处理程序和redis主线程最终是要进行数据交互的。在多numa架构下，如果网络中断处理程序和redis主线程分别属于不同的numa节点，这最终会变成跨numa的间接内存访问，最终也会影响性能。

所以在numa架构下，如果要针对网络中断处理程序绑核，要把网络中断处理程序和redis实例绑定在同一个numa节点下。避免夸numua内存访问。