刘波 发表于:14年08月29日 15:17 [来稿] DOIT.com.cn
刘波首先谈到评价闪存盘的一些指标有很多,速率肯定是其中一项。主要对速率来说有两项,一个是连续读写传输率,另外是随机读写传输率。
回顾一下今年的指标的情况和大概的变化情况,他说:“今年跟去年比较起来,去年我们看到这些盘,直接指标是4个直接指标,还有一些评测指标。今年主流的速率基本上连续读写速率都在2G到3.5这么一个范围。去年我记得在12月份的峰会上,因为在年底,去年都是在1-2的水平,大势来说。基本上今年是1.1到2.5GB的水平。去年年底的时候基本都是在0.5-1.1的水平。随机读I/O也是这个情况,13年的时候基本上是12万到38万,今年主流最高到了80万。写的指标同样提高的比较多,最高到37万的水平。我今天看到还有更高一点的,展台上看到一个介绍。总体来说今年半年了,跟去年比较起来有点像奥运会的精神,更高更快更强,速率更高,读写能力更强。另外还有两个指标,是我做一个比较来说,读写比,一个是连续读和连续写这么一个指标。另外一个就是随机读和随机写的比例,这两个比例是连续读和连续写的差异,这是测试指标。这等于是今年一些产品比去年的读写比更均衡一些,从1.2:1到2.4:1,去年是1.1:4.0:1,随机比也有大的提高,大概就是这么一个情况。这是今年一个印象。”
还有一个情况,在使用和测试的过程中,现在产品都比较多,指标零零总总都是在提升,提升到什么程度,我们怎么样评价这么一个产品,这也是我们测试框架的一个建设。如果把评测这个速度指标和理论指标比较起来来看的话,总是感觉有一些差异。当然今年的指标肯定比去年指标要高很多了,从不管是连续读还是连续写来说,他所占用的理论带宽的比例比去年要高。还有一个比较大的差距,最高来说读的今年占到44%,这是比较高的一个水平。从理论上来说,PCle2.x×8,这个带宽是一个理论值,还有一些编码因素等等。在现有的带宽情况下,我们如何去提高速率,我们有什么途径来做这个事,还是从理论上来想。
找一些原因,还是从公式来考虑,总线带宽=频率×(总线位宽/8)。前面是读写的次数,位宽是读写一次,我们能够拿到的数据量是多少。直观来说,我读写的次数越多,我一次能够拿到的数据越多。在这个理论的指导下,我们看怎么样提高这个速度,有数据总线、地址总线、控制总线、扩展总线、局部总线。我们怎么去提高这个带宽呢?第一方面是不是可以从频率角度考虑这个问题,几个手段,主要是并行,从频率角度来提高存储的速率,还有另外一次拿到速率更高。从什么环节呢?我们从用户角度来说,系统角度来说,从存储部件来说和存储板卡和存储元件四个层面,并行的思路都是可以取的。从用户层面来说,一块卡我们拿不到,我们想拿到更高的,我们可以多插几块,用并行的思路,单块卡的速率没有提高,但是整体的速率提高了。从这个角度来说,我们可以采取什么手段呢?如果这个卡是一个机内的卡,他的数量有一定的限制。我想再提高速率,在一个机箱的机箱内达不到这个要求,我们可以多插几块卡的形式来提升整体应用。作为板卡的制造商来说,从芯片来说,他的每一个芯片的读取范围和带宽是有限的。我们通过增加芯片一级增加他的并行度,我们可以提高他的每一块板卡的并行度。我们提高每一块板卡的并行度,我们可以提高相对来说一块卡对有效带宽的利用。在这个层级来说可能起的效果比在应用层级提高的效率可能要略高一些。今年这些产品,这些指标比去年比较大的变化,这是一块。
还有从元件来说也是这样的一个情况,元件这是一个关于修建层面组织业务规范,关于芯片存储速度的要求,目前有四个版本,从指标情况来看,在运行思路上芯片的制造厂商也是在采取同样的策略。在1.0的时候,这个指标说100也有,60也有。2.0的时候,速率提高到200。去年3.0推出来的时候,速率到了400,今年也是可以达到800。今年的800速率上和去年3.0,差别不大。3.0的时候也提出来800的一个速率,4.0和3.0之间主要的区别是在能耗上他有比较大的降低。去年3.0他的电压是一个水平,今年4.0电压规范比较低。这个表上一个是速率问题提高,第二是看上面的四项,也是比较熟悉,有SDR、DDR2,DDR3。如果仔细看,规范里面这些描述来看,他们应用的都是一个并行的思路,在芯片的读取层面他们作为一个并层。因为对芯片来说,一个是前期的准备阶段,第二阶段是数据读取阶段。在前期数值没有大的变化的时候,我一次取到的数量是不是意味着我速率就可以得到提高,我们通过阅读和组织规范的文本的时候有这样一条思路。实际上规范当中,他提到一个概念,是不是意味着速率一次存取数量上是不是有一个二倍和三倍和多倍。看今年的指标,从产品的指标提升了很多。我们照这个推断,今年产品是去年的3.0。这四个阶段来说,用户阶段、部件阶段、板卡阶段、芯片阶段,不同阶段应用并行思路本身的效率都是有所提升。还有一个特点越是到地层芯片组件的时候,如果我们没有用3.0来设计板卡,前期通过增加板卡数量是不是能够达到用户来提高,我们需要提高一个限度。
随机读写也是有类似的情况,总的来说随机读写的效率从指标来看,咱们谈的都是LPS,LPS和带宽是有一定的关系。实际上LPS突出是我读取频率是多少,读取次数是多少,换一个角度来考虑,如果从我们读取的数量,拿到的有效数量是多少,我们把他折算,今年LPS的读取效率比去年高。他应用的手段来说,目前来看大家提高比较多的主要就系一个增加态势和使用分层存储的概念,冷、温、热。主要用这种手段和目标来提高他的命中率,这是一个。提高目标,我们所达到的效果是提高传输率,另外就是减小写放大。我们从测试的情况来看,各个厂商在提高Cache的名中率方面和效率做了不少工作。去年基本上LPS能够到38万,今年到了80万。随机写的速率也是有相当大的提升,确实有这样的效果,增加Cache和增加算法来说,给性能的提高效率比较显著。
Cache多也是好事,Cache没有什么问题,第一个我们增加Cache的代价和命中率提升的幅度是不太对称。一开始增加Cache,从2G增加到4G效果是很明显的。但是我增加到一定程度以后,我命中率提高,实际上增加频率是很小的。打个比方,比如我们从512内存升级到1G内存,大家的感受是非常明显,觉得很快。比如我内存从1G增加到2G的时候,大家也觉得快了,增加的这种感受就不是特别的明显。再进一步提升,我们把2G内存增加到4G,实际上在用户来说基本就几乎感觉不到有什么变化。为什么?随着Cache的增加,命中率提高,到了一定程度之后这个比例几乎是一个非常平等的一个条件,命中率提高是有瓶颈的。第三在命中率不足时,实际上我们的有效传输率是急剧下降。我们是有感受的,这是我们在测试的时候的一个截图,这是一个SELECT一个数据,从表中读出来存到数据库当中。我们测试和使用的时候,C盘我在执行的时候向D盘平均I/O大小是有1KB,上面C盘也是这样,他延迟不说了,延迟比较小。实际上他的每一个I/O的尺寸,C盘是4.2K,D盘更小,1K。这个数据,执行这条语句,他取得数据量实际多大?我们算了一下,我能够取得数据量大约是1.5兆B是这样的情况。如果都是以4K甚至1K的读写的话,造成的延迟是显而易见。在命中率没有提高的情况下,肯定是执行的时候他还是有很多命中率,有很多没有被命中或者是命中率提高不上去的时候。为什么有这样的情况,怎么解决这个问题,从什么样的思路去解决呢?产生这个问题。
怎么解决呢?有这样一个思路,解决的方案是不是可以从这个邀请函寻找一些答案。主要内容就是尊敬的刘波先生:于某年某月某日在亮马河饭店举行以什么为主题的闪存峰会,我们邀请您作为演讲嘉宾来参加本次峰会下午的闪存技术分论坛演讲,演讲时间是2014年7月31日具体时间,这个信的发出时间是2014年7月15日。我们可以通过这个邀请函我们设想一下,这里面提到几个主要因素,第一他提到了邀请是谁,他邀请了我,这里说明了对象,他要邀请谁。第二他要在什么时间要把我邀请到什么地方来,这是第二个要素。第三个这个信发出时间,在2014年7月15日,今天7月31日有两周,时间比较充裕。设想一下,假如说这个邀请函的发出时间不是在7月15日,如果是在7月25日会有什么情况。我们想对于这个会议来说,我们想应该是没有太大问题,比如我在7月15日接受,我是选择坐车来还是打车来还是开车来,可以选择通行方式,意味着速度。假设这个信邀请发生在7月31日的13:00,发给我的邀请,可能我的选择就非常少了。我只能是打车、乘专车过来才能满足这个要求。为什么这样说?如果这个时间,你要给时间充足的话,我们是不是可以预先把这个数据准备出来,这个是通过测试和使用产生这样一个想法。根据这个思路,我们分析一下这个语句,随机传输率=I/OPS×I/O尺寸。传输量=随机传输率×持续时间。这两个结合起来,我们来看语句的情况就是这样。
语句底下看,SQL Server在编译这条语句的时候占用多长时间,占用141毫秒。在这141毫秒内,我们是不是有可能把这些数据预先把他准备出来。因为我们现在应用了闪存,就为我们实现这种想法就会提供一种可能。如果用以前相当141毫秒,这个可以是忽略。但是对于闪存盘来说,这个141毫秒有可能会带来一个非常显著的变化,是不是就能够提高我们预先给数据准确的时间,提取的有效程度。实际尺寸是1.5兆,141毫秒,肯定是能够传输过来。为什么没有传输过来?因为我们在编译这条语句的时候,没有给闪存盘一个预告,我们没有告诉他我们需要这个数据,我们需要这个数据的范围。我选的这个相对来说数据是比较大的,实际上SQL Server编译时间不可能都是141毫秒,也有3毫秒、4毫秒。甚至有的编译时间,像有的编译完了以后,我就不需要再编译,我们这个时间,我们在各个层面是可以预告。我们没有接到这个数据的预告,接到这个数据的预告时间都晚了。属于1.4兆B的时间,这几个KB来看,需要多长时间,实际上时间很小的。
从应用层级来说,是不是可以考虑在以下这五个层面来说,可以在应用类考虑,提前更好的做一些预告。在数据库层面,在操作系统层面,在存储系统层面,甚至在存储元器件层面是不是也可以做。在存储元器件也有,如果从这个角度来说,我们在应用产业链和应用链各个环节都可以用的。这是我对提高速率和命中率的一个想法。
第一提高速率手段就是并行手段,第二是缓存,第三是设计数据预告。可以应用这些层级来说就是以下几个层面来说。实际上强调一个层面,评价数据指标,评价闪存,提高性能来说,还有其他的延时等等,其他指标也会对速率产生比较大的提升。