取消
搜索历史

    十亿IOPS不是梦?Fusion-io闪存API另类分析

    来源:存储网 2012-07-30 00:00闪存/SSD

      上表为MLC闪存的ioDrive2系列闪存卡规格(点击放大),1 billion方案使用的就是最右边的ioDrive2 Duo 2.4TB。我们注意到它的512字节顺序读IOPS达到了892,000,随机读只有285,000;而512字节顺序写IOPS 935,000和随机写725,000之间的差距却没有这么大。可以确定DRAM写缓存在其中的作用,68微秒的读延迟(SLC闪存的型号为47μs)和15微秒的写延迟也是因为这个。我们猜测对于512字节顺序读来说,其中还有预读的作用——即一次读取一个4KB闪存页面,其中可以包含8个I/O,而512字节随机读一个I/O也要一次读取4KB的闪存页面。

      按照传统块存储的性能计算方法,8台服务器,每台服务器上8块ioDrive2 Duo闪存卡。IO生成器产生的写负载没有说是随机还是顺序I/O?(那我们就按顺序来计算),935,000乘以64等于59,840,000——距离宣称的1,000,000,000 IOPS还有不小的差距。

      尽管笔者不了解Atomic Write API的具体实现原理,但既然可以是顺序写,那么料想它能够将64字节的I/O在服务器内存中合并成适合闪存页面大小的4KB I/O再写入。我们来倒推一下:1 billion IOPS如此转化(64合一)之后就是15,625,000,再除以64(卡的数量)的结果就是每块卡平均244,110。24万的4KB写入IOPS对Fusion-io来说就不是什么难事了吧?

      不知我的思路是否合理?但十亿IOPS似乎只有这个方式才解释得通。就像许多产品标称的性能那样,这个Demo方案测出的也是在理想情况下的水平。有几个应用会固定采取64bytes的大小顺序写入呢?当然,如今的用户估计也不见得需要在实际环境中1 billion IOPS这样高的性能。

      我们再来做个假设:万一将测试模型做些变化,比如把写改为读,那样必须是顺序读才可能实现预读;若将写I/O的尺寸加大,Atomic Write写入合并的效果就没有这么好了,4KB以上的I/O还会超出闪存页面的大小。另外还没考虑到ioDrive在例如数据填满80%,以及长时间随机写产生碎片化对性能带来的影响,当然每一种闪存产品都要或多或少地面对这些问题,这个有点超出这篇文章讨论的范围了。

    (文章为作者独立观点,不代表存储网立场,版权疑问请联系客服。)
    关于我们| 隐私条例| 版权申明| 联系我们

    2018-2022 Copyright © Stor.com.cn