CPU架构对redis的性能影响

2021/8/30 2:06:15

本文主要是介绍CPU架构对redis的性能影响,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

CPU架构对redis的性能影响

主流CPU架构

一个CPU处理器中通常有多个运行核心,每一个运行核心称为一个物理核,每个物理核都可以运行应用程序。每个物理核都拥有私有的一级缓存(Level 1 cache,简称L1 cache),包括一级指令缓存和一级数据缓存,私有的二级缓存(Level 2 cache,简称L2 cache),以及不同物理核共享的三级缓存(Level 3 cache,简称L3 cache)。

现在主流的CPU处理器,每个物理核通常会运行两个超线程,也叫作逻辑核,同一个物理核的逻辑核共享使用L1和L2缓存。

在现在的主流服务器上,一个CPU处理器会有10到20多个物理核。一个服务器上通常会有多个CPU处理器(也叫作多CPU Socket),每个处理器都有自己的物理核,L1、L2和L3以及连接的内存,不同处理器之间通过总线进行连接。

整体如下图,图中有两个CPU处理器,每个处理器拥有两个物理核,每个物理都拥有两个逻辑核。不同的处理器之间通过总结进行通信。

draw.io

可以看出L1缓存和L2缓存是每个物理核私有的,所以当数据或者指令保存在L1和L2缓存时,物理核访问它们的延迟不超过10ns,是纳秒级别,速度非常快。但是L1和L2缓存的大小受限于处理器的制造技术,一般来说只有KB级别的。如果L1和L2中没有缓存需要的数据,就需要访问内存,访问内存的延迟一般在百纳秒级别,这就是L1和L2延迟的10倍。所以不同的物理核还会共享一个三级缓存。L3缓存比较大,能达到几MB到几十MB,这样就能够缓存更多的数据。

从图中还可以看到,我把内存分成了CPU Socket1内存和CPU Socket1内存,内存应该是共享的,为什么这么分呢?是因为如果一个程序先在一个Socket上运行,并且数据都保存到了内存,然后被调度到另一个Socket上接着运行。此时程序再进行内存访问时就需要访问之前Socket上连接的内存,这种属于远端内存访问。和直接内存访问相比,远端内存访问会增加程序的延迟。虽然内存是共享的,但是访问也有差别,所以这里分成了两个部分内存,从物理上来看是一个内存。

在多CPU架构下,一个程序访问所在Socket的本地内存和访问远端内存的延迟并不一致,这个架构称为非统一内存访问架构(Non-Uniform Memory Access,NUMA架构)。

CPU多核对redis性能的影响

在一个CPU核上运行时,程序需要记录自身使用的软硬件资源信息,比如栈指针、CPU核的寄存器的内容等,这些都是运行时信息。为了提高执行速度,程序还会将访问最频繁的指令和数据缓存到L1和L2缓存上。但是在多核CPU场景下,一旦程序需要在一个新的CPU核上运行时,那么需要将运行时信息重新加载到新的CPU核上。而且,新的CPU核的L1、L2缓存也需要重新加载数据和指令,这会导致程序的运行时间增加。

对于redis来说,当上下文切换时,Redis主线程的运行时信息需要被重新加载到另一个CPU核上,而且,此时,另一个CPU核上的L1、L2缓存中,并没有Redis实例之前运行时频繁访问的指令和数据,所以,这些指令和数据都需要重新从L3缓存,甚至是内存中加载。这个重新加载的过程是需要花费一定时间的。而且,Redis实例需要等待这个重新加载的过程完成后,才能开始处理请求,所以,这也会导致一些请求的处理时间增加。

在CPU多核的情况下,redis实例如果被频繁调度到不同的CPU核上运行的话,那么请求的处理时间影响就更大了。每调度一次,一些请求就会受到运行时信息、指令和数据重新加载过程的影响,这就会导致某些请求的延迟明显高于其他请求。

为了避免Redis总是在不同CPU核上来回调度执行,可以把redis实例与CPU核进行绑定,让redis固定运行在一个CPU核上。可以使用taskset命令把一个程序绑定在一个核上运行。

taskset -c 0 ./redis-server

其中参数-c后面需要加绑定的核编号。上面命令的意思就是将redis实例绑定在0号核上面。

在CPU多核的环境下,通过绑定Redis实例和CPU核,可以有效降低Redis的尾延迟。当然,绑核不仅对降低尾延迟有好处,同样也能降低平均延迟、提升吞吐率,进而提升Redis性能。

NUMA架构对redis性能的影响

为了提高redis的网络性能,把操作系统的网络中断处理程序和CPU核绑定。这个做法可以避免网络中断处理程序在不同核上来回调度执行,的确能有效提升Redis的网络处理性能。网络中断处理程序是要与redis进行数据交互的,所以需要知道redis实例是绑定在哪个核上了,因为这会关系到redis访问网络数据效率的高低。

下面的图介绍了redis和网络中断程序的数据交互过程:网络中断处理程序会先从网上硬件中读取数据,然后交数据写到操作系统内核缓冲区中,内核会通过epoll机制触发事件来通过redis,redis再把数据从内核缓存区拷贝到自己的内存缓冲区。

draw.io

所以在CPU的NUMA架构下,当网络中断处理程序、redis实例分别和CPU核绑定后,就会有一个潜在的风险:如果网络中断处理程序和redis各自绑定的核不在同一个CPU Socket上,那么redis读取网络数据时就需要跨CPU Socket访问远端内存。所以最好把网络中断程处理程序和redis实例绑定同一个CPU Socket上,这样redis就能够直接从本地内存中读取网络数据了。

需要注意的是,在CPU的NUMA架构下,对CPU核的编号规则,并不是先把一个CPU Socket中的所有的逻辑核编完,再对下一个CPU Socket的逻辑核进行编码,而是先给每个CPU Socket中每个物理核的第一个逻辑核依次编号,再给每个物理核的第二个逻辑核依次编号。

假设有2个CPU Socket,每个Socket上有6个物理核,每个物理核又有2个逻辑核,总共24个逻辑核。可以执行lscpu命令,查看到这些核的编号:

lscpu

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

可以看到,NUMA node0的CPU核编号是0到5、12到17。其中,0到5是node0上的6个物理核中的第一个逻辑核的编号,12到17是相应物理核中的第二个逻辑核编号。NUMA node1的CPU核编号规则和node0一样。所以一定要注意编号方法,不要绑错了。

绑核的风险和解决方案

绑核的风险

redis除了主线程以外,还有用于RDB生成和AOF重写的子进程,还有一些异步线程来执行一些不需要实时的任务。当把redis绑到一个CPU逻辑核上时,就会导致子进程、后台线程和redis主线程竞争CPU资源,一旦子进程或后台线程占用CPU时,主线程就会被阻塞,导致Redis请求延迟增加。

解决方案

第一种解决方案是一个Redis实例对应绑一个物理核。在给Redis实例绑核时,不要把一个实例和一个逻辑核绑定,而要和一个物理核绑定,也就是说,把一个物理核的2个逻辑核都用上。还是以刚才的NUMA架构为例,NUMA node0的CPU核编号是0到5、12到17。其中,编号0和12、1和13、2和14等都是表示一个物理核的2个逻辑核。所以,在绑核时,使用属于同一个物理核的2个逻辑核进行绑核操作。使用以下命令将redis绑定到第一个物理核上面:

taskset -c 0,12 ./redis-server

和只绑一个逻辑核相比,把Redis实例和物理核绑定,可以让主线程、子进程、后台线程共享使用2个逻辑核,可以在一定程度上缓解CPU资源竞争。但是,因为只用了2个逻辑核,它们相互之间的CPU竞争仍然还会存在。

第二种方案是修改redis的源码,把子进程和后台线程绑定到不同的CPU核上。首先先介绍一下通用的编程绑核方法。需要使用操作系统提供的一个数据结构cpu_set_t和3个函数CPU_ZERO、CPU_SET和sched_setaffinity:

  • cpu_set_t数据结构:是一个位图,每一位用来表示服务器上的一个CPU逻辑核。
  • 以cpu_set_t结构的位图为输入参数,把位图中所有的位设置为0。
  • CPU_SET函数:以CPU逻辑核编号和cpu_set_t位图为参数,把位图中和输入的逻辑核编号对应的位设置为1。
  • sched_setaffinity函数:以进程/线程ID号和cpu_set_t为参数。检查cpu_set_t中哪一位为1,就把输入的ID号所代表的进程/线程绑定在对应的逻辑核上。

知道了这些东西就容易实现绑核操作了:

  1. 创建一个cpu_set_t结构的位图变量。
  2. 使用CPU_ZEOR函数,把cpu_set_t结构的位图所有的位都置为0。
  3. 使用CPU_SET函数,把需要绑定的逻辑号编号在cpu_set_t结构的位图设置为1.
  4. 使用sched_setaffinity函数,把程序绑定在cpu_set_t结构位图中为1的逻辑核上。

代码如下:

//线程函数
void worker(int bind_cpu){
    cpu_set_t cpuset;  //创建位图变量
    CPU_ZERO(&cpu_set); //位图变量所有位设置0
    CPU_SET(bind_cpu, &cpuset); //根据输入的bind_cpu编号,把位图对应为设置为1
    sched_setaffinity(0, sizeof(cpuset), &cpuset); //把程序绑定在cpu_set_t结构位图中为1的逻辑核

    //实际线程函数工作
}

int main(){
    pthread_t pthread1
    //把创建的pthread1绑在编号为3的逻辑核上
    pthread_create(&pthread1, NULL, (void *)worker, 3);
}

对于redis来说,它是在bio.c文件中的bioProcessBackgroundJobs函数中创建了后台线程。bioProcessBackgroundJobs函数类似于刚刚的例子中的worker函数,在这个函数中实现绑核四步操作,就可以把后台线程绑到和主线程不同的核上了。

和给线程绑核类似,当使用fork创建子进程时,也可以把刚刚说的四步操作实现在fork后的子进程代码中,示例代码如下:

int main(){
   //用fork创建一个子进程
   pid_t p = fork();
   if(p < 0){
      printf(" fork error");
   }
   //子进程代码部分
   else if(!p){
      cpu_set_t cpuset;  //创建位图变量
      CPU_ZERO(&cpu_set); //位图变量所有位设置0
      CPU_SET(3, &cpuset); //把位图的第3位设置为1
      sched_setaffinity(0, sizeof(cpuset), &cpuset);  //把程序绑定在3号逻辑核
      //实际子进程工作
      exit(0);
   }
   ...
}

对于Redis来说,生成RDB和AOF日志重写的子进程分别是下面两个文件的函数中实现的。

  • rdb.c文件:rdbSaveBackground函数;
  • aof.c文件:rewriteAppendOnlyFileBackground函数。

这两个函数中都调用了fork创建子进程,所以,可以在子进程代码部分加上绑核的四步操作。使用源码优化方案,既可以实现Redis实例绑核,避免切换核带来的性能影响,还可以让子进程、后台线程和主线程不在同一个核上运行,避免了它们之间的CPU资源竞争。相比使用taskset绑核来说,这个方案可以进一步降低绑核的风险。



这篇关于CPU架构对redis的性能影响的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程