突破硬件瓶颈(一)：Intel体系架构的发展与瓶颈挖掘

分布式存储 | 北京大道云行科技有限公司

软件定义存储SDS正在从容量型向性能型演进，千万级IOPS和微秒级低延迟，非常具有挑战性。3节点标准x86服务器，能否有可能实现1000万IOPS与200us低延迟？这个可以有。硬件性能并不是瓶颈所在，软件颠覆才是关键。

想要取得如此强的性能，必须要有突破时下存储软件对于硬件利用的瓶颈。
而要突破这些瓶颈，就需要对硬件有深入的了解，而后利用软件想方设法突破，或者绕过他们，实现性能的腾飞。
本文是突破硬件瓶颈系列文章的第一篇，分析Intel体系架构带来的瓶颈。
存储的性能越高，则对延迟越敏感，当IOPS提高到百万的时候，纳秒（ns）级别的延迟也必须考虑进去。
想达到这种性能，必须着力降低软硬件体系内的一切延迟，这些延迟往往来自于硬件体系本身，因此，分析硬件体系架构是有必要的。
目前市面上的服务器存世量较高，横贯多种架构，单一分析某一种架构并没有很高的实际价值，采用从前到后、从低端到高端的分析方式，不仅能遍历每代架构的优缺点，也能从Intel的进步过程中，明确瓶颈的所在。

Intel体系架构一瞥

在普遍采用的intel体系架构中，CPU早已不仅是服务器的运算核心，他也是控制内存、外部存储的核心。
集成内存控制器（integratedmemory controller，IMC）早已位于CPU中，它负责调度内存进行读写操作。
PCI-E控制器也位于CPU中，它负责控制高速设备（如显卡、网卡、NVMe等）。
即便是芯片组也是通过DMI总线，间接由CPU控制。
以某块C612双路主板为例，可以看出CPU的核心地位：

因此，想要找到延迟的根源，必须深挖CPU内部的构造。

01 低端服务器架构设计

曾几何时，CPU的内部架构非常简单，如这颗四核心CPU为例：

最左侧的蓝色部分是集成显卡（iGPU），占据了大量面积（服务器CPU屏蔽这部分）。
四个红色的计算核心（core）旁边则是绿色的L3 Cache缓存。
最右方则是前端部分（agent），包含PCI-E、DP等外部控制器。
上方的黄色部分连接了内存。
几乎所有的部分，都由一条高速通道——Ring总线连接。
Intel绝大多数2-4核心CPU设计都是如此，甚至少数6核心CPU也是这种设计，目前有大量仍在服役的服务器CPU也采用了近似设计。
然而这种设计注定不适合更多核心的CPU，当核心变多，Ring总线势必拉长，而经过的Core越多，则可能造成更多的中断。
四核心的内存理想延迟仅为50ns，而到八核心，延迟就增加到了70ns左右，而且一旦出现IO中断，延迟可能会翻倍激增。

02 中端服务器架构设计

深耕行业多年的Intel深知这种延迟的积累，终究会影响性能，所以Intel后续的CPU使用了环形总线。
单路变环路，吞吐量不仅增加了，还减少了中断造成的延迟。

核心更多，需要缓存的数据也更多，命中率不可避免的降低。
intel将Cache包含关系改变，并且改变缓存配比，使对外速度翻倍（可以理解为L3做了“镜像”），同时引入了CMS，用以进一步降低延迟，L3 Cache成为了环形Ring总线上的“服务区”，不再仅对自己的核心服务，大大提高了缓存利用率。
缓存利用率和速度的提高，是总线中断次数和时间减少，再加上总线通道数增加，都大大缓解了多核心下的延迟。
Intel的6-8核心CPU多数采用此种设计方法，现服役的大量中端服务器，均采用这种设计的CPU。

03 高端服务器架构设计

但是核心的进一步增加，造成了新的瓶颈：更多的核心，需要搭配更多的iMC，如果我们八核心需要双通道内存，那么十六核心就需要四通道内存。
如果iMC都在一侧，则远端的核心内存延迟势必增大，更严重的是Ring的数据分布也会不平均，近IMC一侧延迟增多，造成“前方吃紧，后方紧吃”的结果。
CPU在BroadWell EX中架构采取了笨办法，如果一个环不够“串”起来那么多的核心，那就两个环吧，每个环连接一个IMC。
这种做法解决了一个问题，却又创造了另外一个问题，一个IMC体系之中的延迟降低了，但是两个IMC之间的连接效率低下，简直是将两块CPU涂了“胶水”黏在一起。
因此，Intel不得不再次改变设计，采取了图右侧中的方法。
如果画个草图，就是原来是“串”起来，现在则是“格”起来。
原来每两个实体之间只有一条路，且单向，现在则是有三条路。
从前intel是左边的设计，这里每一个方块都可能代表了IMC（内存控制器）、CORE等结构。
而右边的是Intel的新设计，不仅总线数量增加了，也把system agent里的内存控制器拎了出来，装上CMS模块，用于减少延迟。
新的总线被Intel成为网状（Mesh）总线，如下图：
蓝色双向箭头代表通过针脚与外部联通的部分，橙色是Mesh总线。
以SKylake-SP HCC SoC die（完整18核）为例，下图为该CPU （Xeon E7 8895-V3以及E5-4669 V3等）DIE的电镜图：
可以看到，除了四周的外部接口和触电部分，中央的核心部分被Mesh整齐的分开。
Mesh包含纵向和横向，如果拆开来看，他们的作用并不相同，这里不再过多赘述。

需要指出的是，Mesh架构虽然在高核心数（12核）以上，拥有比Ring低的延迟。
但是即便使用了Mesh，也不可能让16核心的CPU延迟和4核心一样低。
Mesh的意义在于，18核心的理想内存延迟为70ns左右，虽然高于四核心单Ring的50ns，但是平均每核心的延迟远低于单Ring。
由于走线压力，Agent仍然处于一端，PCI-E、UPI的延迟在一定程度上被舍弃了。
另一边，这种设计下，CPU的成本迅速增长，因为半导体工艺良品率的关系，四倍的核心数（面积），往往能造成十倍以上的成本。
正因为单CPU堆核心对于成本的提高太快，我们不得不使用多路CPU系统。
截至目前，新品Intel服务器CPU仍采用这种Mesh设计。
这种设计下，大量的CPU寻址少数的IMC，且延迟不一，每个CPU均有权寻址任何IMC下的任何内存。

04 服务器架构共性问题

由于Intel本身内存调度不够智能，容易造成调度混乱，满载时延迟会爆发性增高。
超线程技术加剧了这一现象，双倍的逻辑处理器造成更高的延迟。
实际上，超线程技术更多的适合虚拟化，以及低功耗、低负载场景，在满载情况下，Intel的超线程技术已经被证明无法增加额外的算力。
现代服务器多为双路，甚至四路、八路。
多路CPU要协同工作，通过UPI（或QPI）连接，跨过“遥远”的主机板电路，出现延迟。
在常见的逻辑中， CPU中所有核心数都逻辑平等。

正因如此，软件通常会随机调度CPU，例如在CPU1中拿出一个核心，又从CPU2中拿出一个核心。
在单颗CPU中，这样延迟并不会太多。

但是在多颗CPU情况下，延迟就可能剧增，一颗CPU可能会需要频繁的绕过主机板，并且再向另一颗CPU发送请求，才能调用并不属于它的IMC，进而调用隶属这颗IMC的内存。
这好比仅想买一包泡面，明明门口有小卖铺，却跑到了另一条街，再找人帮忙代购一包方便面。
这种巨大的延迟是高性能存储服务器所不能容忍的，因此NUMA（Non-Uniform Memory Access）功能应运而生，它标识了内存的跨NUMA节点访问请求，为软件干预调度提供了可能。
至此，我们用实际测试对内存调用产生的延迟做一个总结，下面三行分别是以Xeon E5单路、双路、以及E7 v四路下，CPU运行时钟为3Ghz（时钟频率会影响内存延迟），延迟如下表：

由表中可见，本地内存访问延迟为67ns，而远端访问的双路、四路分别为125ns、140ns。
同样，内存性能的增加也远不是线性的，tot cycles代表每次循环处理事务，可以看到，四路系统的处理速度不到单路的两倍。

05 Intel体系架构瓶颈总结

由以上分析可以得出Intel体系架构目前面临的四大问题：
1、过多核心、线程导致内存的调用效率低下，延迟提升
2、多路CPU导致内存的延迟进一步增高
3、核心的缓存利用率不够高，命中率低
4、如果出现上下文切换，过多的CPU核心会导致更严重的延迟

如果能解决这些问题，就能从CPU和内存调度的角度，提升存储的性能，打破固有的“瓶颈”。