注：本文内容引用自张洋老师的知乎文章
https://zhuanlan.zhihu.com/p/694541950，他
是一位存储研发专家。
前言
随着"信创"的东风吹遍大江南北，各家公司都开始了国产化的适配道路。zStorage团队当然也没有缺席，去年我们适配了华为的鲲鹏架构，整体性能水平达到了Intel架构的70%以上。今年我们开始着力于海光CPU架构的适配。与鲲鹏架构相比，海光的适配难度相对更小。因为海光也是x86架构，海光CPU通过与AMD的合作，获得了ZEN1架构和X86指令集的永久使用权，并且在此基础上开发了7、5、3系列处理器，分别定位于高、中、低档服务器市场。所以zStorage对于海光CPU架构的适配，主要问题不在于编译以及基本功能上，而是在于性能调优。本文打算记录zStorage在海光服务器上的性能调优过程中遇到的问题和解决方法。
调优过程
解决不能正常运行的问题
虽说海光也是x86架构，不过我们所使用的这套服务器的CPU是Hygon C86 7360 24-core Processor，并不支持AVX512等指令集。所以我们首先在海光服务器上重新编译了zStorage，解决了指令集不兼容的问题。此外还存在一个比较大的软件部署上的问题。在Intel服务器上，zStorage支持1个或者2个NUMA nodes的情况，并且2 NUMA nodes作为标准部署环境。其中ChunkServer（简称CS）运行在NUMA node 0上，FrontEnd（简称FE）运行在NUMA node 1上，这样按照NUMA亲和性部署，zStorage具有最佳的性能表现。
（注：CS和FE是IO路径上的两个主要进程，直接关系到IO的性能。）
海光服务器上有两个socket，分别插了一个CPU。每个socket内部又被分为了4个DIE，所以在操作系统看来一共是8个NUMA nodes。每个NUMA node（或DIE）上有1根16GB内存。zStorage默认的2 NUMA nodes的部署方式，只能利用两个NUMA nodes的内存，由于不能充分使用多NUMA nodes的内存，达不到最佳性能部署的要求。
那么在不改软件代码的情况下，要么增加至16根内存条，这样可以达到开启2 NUMA nodes模式的条件；要么关闭NUMA模式，将所有资源聚合为单个NUMA node。为了能够快速将zStorage运行起来，关闭NUMA，使用单个NUMA node是最快的选择。
单NUMA node的性能问题
将多NUMA nodes的资源聚合为单个NUMA node的方式存在天然的性能问题。通过修改BIOS设置关闭NUMA模式，并开启内存交织访问，这种模式下，操作系统只会看见一个NUMA node。实际上会出现任何一个CPU核访问内存时，不会只访问本DIE之内的内存，而是会跨越DIE和socket交叉访问内存。这种模式下，标准性能测试（4k 7:3随机混合读写）只达到了53万IOPS，仅为Intel服务器25%的性能水平。所以还是得寻求多NUMA nodes的支持，以达到最优性能。
内存带宽基准性能测试
跨越NUMA node访问内存，性能不友好，但这仅是一个比较模糊的结论，不直观。到底跨越NUMA node性能会差到什么程度，确是没有一个定量的参考。因此，我在Intel服务器上进行了一个内存带宽的基准性能测试。（详细解读，请参考：《
分布式存储性能调优 - sysbench内存带宽测试详解
》
《》
）
有了这个数据之后，对于内存带宽的真实表现，算是有了一个定量的参考。后续在海光服务器上，如果怀疑是内存带宽问题，那么可以用同样的方法，做对比测试验证。
增加内存条，开启2 NUMA nodes
在适配多NUMA nodes之前，了解zStorage在海光服务器上的最佳性能是有必要的。因此，通过将每个存储节点再增加8根内存条，然后在BIOS中设置内存在DIE间交织，即可开启2 NUMA nodes模式。这种模式下，CPU核会在socket内的4个DIE间交叉访问内存，但是不会跨越socket访问内存。简单验证了下内存带宽性能，相比Intel的测试数据，没有明显的差距，内存方面的瓶颈认为已经排除了。
实验1：ChunkServer（简称CS）绑定到NUMA node 0，使用20个逻辑核（10个物理核）；FrontEnd（简称FE）绑定到NUMA node 1，使用8个逻辑核（4个物理核）。按照这个方式测试了基准性能，只有70万IOPS，未达到预期。
实验2：将CS和FE都绑定到NUMA node 0上，CS使用17个核心，FE使用7个核心，共使用24个物理核。这块CPU上有24个物理核，48个逻辑核，在选择这24个逻辑核的时候，从每个物理核上挑一个逻辑核，确保充分发挥出CPU的性能。这种绑核方式IOPS达到了100万。
这两个实验说明zStorage在海光服务器上，使用两个socket存在性能问题，原因暂时未知。（这里没有直接使用全部的逻辑核心，是为了保证性能测试和标准20+8的绑核模式一致。）
模块时延分析，增加IB卡
利用zStorage内置的时延分析工具（z_trace）分析模块时延，发现主要的瓶颈在于网络通信RPC模块。下发IO负载的同时，使用IB工具测试IB网络的时延，发现时延很高，说明确实是网络达到了瓶颈。停掉zStorage的进程，单独测试IB卡，发现双向带宽只有11GB/s，而同样的测试在Intel服务器上可以达到22GB/s。
继续分析发现海光服务器的PCI插槽带宽相比Intel要差。所以下一步继续加硬件，每个节点增加一张IB卡。增加IB卡以后，效果立竿见影，IOPS达到了130万。相比于Intel服务器的200万IOPS，130万这个数据也不是那么难看了，毕竟国产服务器还得给它一些时间成长。
130万IOPS，相比于刚开始的53万IOPS，确实看起来舒服多了。通过增加内存条来提升性能，至少可以作为一个保底方案。但是加内存的方式，性价比不那么高。最具性价比的方法是zStorage可以有效利用8个NUMA nodes的内存和CPU，达到理想的性能。
