【冬瓜哥手绘】它保你上线性能也吊炸天！

       在之前的文章《为何测试时性能吊炸上线却掉渣？》一文中冬瓜哥向大家介绍了这个问题的本质原因，就是IO路径的时延太高而导致同步IO场景吞吐量上不来。

    对于固态存储系统，固态盘本身的时延非常低，而此时虽然利用传统的高时延协议栈也能获得远高于机械盘的性能，但是离着固态盘的极限性能就差了一大截了。什么原因？还是时延高导致的，走路的时间比干活的时间还长，产量当然就上不来了。

    文章发出后，反响强烈。华云网际（FusionStack）的CTO王劲凯老兄发消息说他们的FusionStor分布式存储系统能保你上线性能也吊炸天。基于SSD盘，他随手一跑就跑出5.3GB/s的随机4K读吞吐量。冬瓜哥换算了一下，这可是138万的IOPS。

    7:3比例的读写测试数据也相当牛。

    他说这对FusionStor是小菜一碟，目前FusionStor的单节点极限性能可以达到200万IOPS，目前正在通过从CPU、缓存等体系结构底层的优化从而向1000万IOPS迈进，注意，是单节点，而不是整个集群系统。

    冬瓜哥：单线程，QD=1时呢？模拟同步IO场景啊。老王又给出了下列数据：

单线程下达到这个性能已经非常不错了，读时延在106微秒，算上SSD执行IO时候的时延，整个FusionStor协议栈对IO时延控制的很好。

       FusionStor把单个IO软件堆栈处理时间压缩到5个微秒（不含SSD的读写时间）。单个CPU core 在10万IOPS情况下，平均延迟能控制在400微秒。在10个CPU core的服务器上，FusionStor可以提供100万IOPS的处理能力。预计到2017年底，FusionStor的单个IO软件堆栈时延将要压缩到2个微秒，在10 CPU core的服务器上将能提供一千万IOPS的处理能力。

 

怎么做到的

    FusionStor定位为Flash优先的软件定义存储。其设计的原则保持Flash裸金属性能的前提下，实现高可用和可管理性。为了保证Flash的裸金属性能，FusionStor绕过操作系统，采用低延迟的方案重新实现和存储相关的软件堆栈。传统的模型有几个缺陷：

 

• 一个任务需要在多个CPU core之间传递，需要锁或者原子操作。在many core场景下，锁和原子操作开销相对较大。

• L2 cache命中率低

• 跨NUMA节点带来开销

• 操作系统的IO协议栈开销较大

 

    FusionStor采用了OS-bypass的编程模型，在裸金属的基础上完全重新实现了和存储相关的软件堆栈。主要特征如下：

 

• 编程模型：run-complete

• 任务调度：coroutine方式。用户态管理多线程，多线程间配合切换而不是靠外部中断等强制切换，能节省开销，同时实时性更好。这被称为协程方式。

• 事件处理：polling方式。相比中断方式具有更好的性能，有效降低时延，充分利用时间片。

• 多核同步：None。经过优化的IO路径，去除了多核间同步。

• 硬件访问：stack-bypass

• Network：RDMA/DPDK

• Flash：SPDK   

• Mem：huge page

 

 

    这些可都是前沿技术。原本冬瓜哥认为可能FusionStor无非就是使用了RDMA来降低网络协议栈带来的时延，没想到无锁、无同步、协程、Huge Page这些都用上了。这里面协程这个思路，冬瓜哥之前还真没有看到其他厂商尝试过。

    在这里冬瓜哥画了几张IO路径图，下面这个是FusionStor的。还有NVMe盘的和传统存储的。大家可以对比一下。

 

 

想要这张冬瓜哥手绘图的朋友可以留邮寄信息到公众号，顺丰到付。

相关阅读：

【冬瓜哥熊文】大话流水线（1）~流水线基础理论

【冬瓜哥熊文】大话流水线（2）~队列、时延与并发

‍