本文内容非贸易用途可无需授权转载，请务必注明作者及本微信公众号、微博ID：唐僧_huangliang，以便更好地与读者互动。
据相识，利用3DXPointMemory的OptaneP4800X在国内已经开始少量供货，除了一些测试过的人之外，已经开始有采购的用户了。有朋侪问我，这个卡在测试中有没有必要留意/调优的地方，以便更好地发挥其性能代价。
别的，假如说WindowsServer2012和2016的内核I/O服从有差别，您可否先猜测下性能结果？
接系列前文：
《IntelOptaneP4800X评测（序）：不消缓存和电容掩护的SSD？》
《IntelOptaneP4800X评测(1)：好钢怎样用在刀刃上？》
《OptaneP4800X评测(2)：Oracle170万TPM意味着什么？》
前面已经写过FIO和Oracle数据库的测试，这篇重要围绕Windows下的Iometer测试结果，趁便谈谈性能发挥方面的一些留意事项。程度有限，不敷之处请各人多指正:）
传统停止I/O在Optane面前显出瓶颈
点击放大图片，以下同
起首表明一点，未经特别设置的环境下，我在WindowsServer2016（自带NVMe驱动）下测到的P4800X读延时最小为20μs左右，没有到达当初在《再谈3DXPoint：延时、QoS与队列深度》中列出的官方规格。Why？
Intel标称的延时是QD（队列深度）=1小于10μs，我也看了国外网站的评测，要到达这个性能传统IRQ停止装备访问模式应该是比力困难，polling（轮询）的服从会更高。而polling也分为内核态和用户态实现，假如利用FIO、Iometer如许的工具测试块装备，我在高版本Linux内核下测到了11μs左右；别的尚有个“终极大法”——用户态下的SPDK，后续文章中我会给各人讲讲这部分测试。
这里趁便保举冬瓜哥的一篇科普文《IO协议栈前沿技能研究动态（2015存储峰会分享）》
回过头来说，大概大多数企业存储用户如今还用不到polling，那么传统停止I/O的性能也有参考意义。我们接着讨论上面的对比图表：
IntelOptaneP4800X与SSDP3700相比，在低队列深度的环境下IOPS和延时上风都很显着。P4800X在QD=32时就能测出最大IOPS58万，而P3700则要到QD=128才华到达标称的46万。
用WindowsServer2016上来直接测，写延时也没有低于20μs
再来看随机写。与随机读差别的是，由于SSD上有写缓存做优化归并等，低队列深度时两款卡拉不开差距（前文中我也提到了NAND闪存SSD这个Cache和掩护电容每每大一些）。IntelSSDP3700在QD=8时已达最大性能18万IOPS（此时OptaneP4800X为23万），而P4800X到QD=32才完全发挥出上风，我们测出的48万随机写IOPS靠近50万的官方规格，此时的耽误为66μs（P3700则到达170μs）。
在《不消闪存了，OptaneSSD为何还要28%的OP？》中我曾提到过，3DXPointMemory介质不消擦除就能直接覆盖写入，以是P4800X不必要大容量DRAM写缓存的计划，均匀写延时只是比读略高。而P3700在QD=16～32之间有一个交错点，高出这个点读IOPS和延时表现就比写要好了。
对于QoS延时，SSD的写缓存就比力无力了。下一篇评测中，我还将给各人列出95%-99.999%QoS延时的对比，一些官方spec中没有的数值盼望可以或许通过我们的测试给各人补上。
为什么要绑核：IRQ打散对CPU开销的影响
接下来一个题目，就是动辄几十万IOPS，CPU的开销怎样？在Iometer里每个Worker对应一个线程，假如单一Worker测试增长QD到达肯定IOPS就会把单个CPU核心耗满。我观察了这时的CPU资源占用环境，想到了一个进步性能服从的大概。
上面的截图，还是来自本系列测试利用的服务器——DellPowerEdgeR830，设置了4颗10核IntelXeonE5-46101.8GHzCPU。上面是关闭超线程时每个内核表现的小窗，如许看直观一些，假如打开HT由于逻辑处理惩罚器太多只会表现一个百分比数字了。
各人可以观察到有8个CPU核心一度会合占用较高——由于我在测试中先做了8个线程的绑核操纵，而后取消了绑核，按照默认方式跑8个Worker测试。后半程可以或许变更的CPU资源还是相称于8个核，但Windows体系主动会将其打散到多个核心上，就像irqbalance的结果。颠末反复对比测试，验证了绑核设置对性能是有影响的。
不到60万IOPS，CPU总体占用率高出20%，将近靠近10核1.8GHzE5-4610CPU的处理惩罚资源了。从这一点上来看Windows的服从没有Linux高。
这里还是利用WindowsServer2016，默认超线程打开的测试结果。当QD=1时，设置绑核之后OptaneP4800X的IOPS从46067进步到57858，延时从21μs低落到17μs，同时CPU占用率也有降落。可见OS的停止打散在有些环境下是有副作用的。
在一个Worker将QD增长到4时，XeonE5-4610v4处理惩罚器的单个1.8GHz核心开始成为瓶颈。绑核后可以测到145828IOPS，2.8%的CPU占用率根本上代表占满了40核心中的1个，大概把别的程序的一点开销也统计进去了吧。
当Worker*QD加大到16*2时，由于已经是多线程I/O操纵，绑核的结果不再显着，都可以到达OptaneP4800X的最大性能。而如果在超线程关闭的环境下，绑核的表现又不一样，大概可以说不绑核测试的结果比HT打开时略差。为了不打乱各人的思绪，本文还是先分析默认设置的环境。
随机写测试的环境与上面雷同，QD=1时绑核结果仍旧不错，而到QD=4就掉过来了。总的来说高队列深度下绑核的作用不再显着，大概有小的副作用。同时我也按照同样方式测试了IntelP3700随机写，结果和OptaneP4800X雷同，也就是说这一段的履历对于Windows下差别的高性能SSD都应该实用。不外NAND闪存卡的低QD随机读性能与Optane差距较大，以是绑核受益没那么多了，比如在100μs底子上低落几个微秒就不轻易察觉了吧。
17μs的延时并不能让我们止步，更紧张的是我也想验证差别版本操纵体系下的表现，请看接下来的对比。
WindowsServer2016输给了2012？但不是全部
大概是工程样品的缘故，我手头这块OpteneP4800X最大IOPS性能偶有小幅颠簸。文档里标称的随机读55万，我在测试中偶有碰到52万左右的环境。
换用WindowsServer2012R2之后，我们验证了绑核带来的结果。QD=1随机读延时低落到15μs，单个CPU核心贡献的IOPS也高出了16万，这可以说WS2016的服从不敷高吗？
注：CPU的单线程性能与主频和核心效坦白接相干，我们测试的PowerEdgeR830服务器支持全系列XeonE5v4处理惩罚器，这台设置的E5-4610v41.8GHz在Linux下单核可以轻松测出20万以上IOPS。
上面图表中我们也看到了不正常的环境：QD=32时绑核之后性能反而达不到最大IOPS，延时和CPU占用率也飙升，险些把16个CPU核心给耗满了。假如关闭超线程，WS2012体系下绑核没有这个题目，大概必要更进一步的调优吧。这应该不是SSD的题目，列出来只是供各人参考。
WindowsServer2012R2随机写的环境与随机读雷同。QD=1绑核在54744IOPS时CPU总体占用率只有0.83%，相比之下WS2016的内核服从显得低了一点。
次序读写带宽简测
思量到单位容量代价的因素，大数据块次序I/O性能应该不算OptaneP4800X的亮点。不外既然也有朋侪问过我这方面，估计还会有人想相识吧。
IntelP3700官方指标SeqR/W:Upto2800/2000MB/s，不外是按照MB/s=1,000,000bytes/second的单位，我们测试的MiB则是1,048,576bytes。
如上方图表，OptaneP4800X的64KB次序读带宽在QD=2时就到达最大值2500MiB/s了。而IntelSSDP3700的环境有点特别，QD=1时的读带宽较高，而QD增长到2-4却有些不稳固，还出现过低于1000MiB/s的环境。由于带宽测试不是我们的重点，只是短时间跑了一下没有穷究，结果仅供各人参考。也不打扫是我手头测试卡的个体表现。
次序写的表现在我们料想当中，OptaneP4800X在64KBQD=8时写带宽到达了2185MiB/s，比P3700高一些。
总结与预测：SPDK、QoS延时
简单回顾下本文的Iometer测试，除了P4800X未能发挥出标称的延时（缘故起因前面表明过了）之外，我们还发现了Server2016和2012体系服从上的小差别，以及绑核带来的结果。有些结论涉及到Windows体系的机制，不但实用于Optane和IntelSSD，盼望能给各人一些参考吧。
下一篇我将转回到Linux体系。在Intel给出的图表中，同样利用单一XeonCPU核心，Linux内核IOPS最高可以跑到40-50万IOPS，而改用SPDK之后则高达350万以上。
我估计Intel这个测试用的CPU主频到达3.5GHz左右。那么我手头PowerEdgeR830服务器上的XeonE5-46101.8GHz假如SPDK跑到上面列出的一半，应该也能用1个核心支持OptaneP4800X和P3700两块卡加在一起了。
究竟是否真的云云？P4800X的延时毕竟能低落到多少？请各人拭目以待…
注：本文只代表作者个人观点，与任何构造机构无关，如有错误和不敷之处欢迎在留言中品评指正。进一步交换技能，可以加我的QQ/微信：490834312。假如您想在这个公众号上分享本身的技能干货，也欢迎接洽我：）
恭敬知识，转载时请保存全文，并包罗本行及如下二维码。感谢您的阅读和支持！《企业存储技能》微信公众号：huangliang_storage
汗青文章汇总（传送门）：https://chuansong.me/account/huangliang_storage
↓↓↓
CopyrightYourWebSite.SomeRightsReserved.
京ICP备2023016396号-1PoweredByESCLINK.
我要评论