昨天晚上写了个代码，测试了下目前我这个1000块钱的SSD的随机读能力。
主机配置 i5 4核(两物理核),8G内存 linux 内核版本 2.6.18-128.el5
一个50G的文件(>> 8G内存 ,防止全缓存至内存中 page cache)，随机seek到一个位置，读取100字节，返回，基本模拟了rmdb和nosql 根据主ID读取某条记录的场景(忽略索引ID时间).
SSD在开启10个channel时读数据达到峰值 读取1百万条随机ID的数据，用时9.0S
然后接USB连一个5400转的机械硬盘随机读1万条，注意是1万，不是100万，花了90s。
顺序写20G文件, SSD 150MB/s 5400转机械硬盘 80MB/s ,一倍差距. 所以顺序写文件的10K转速的机械磁盘应该和SSD不分上下的. 基于机械磁盘的这种特点，存储系统中，特别是NoSql的内存数据库，基本会用这类做binlog日志,先写文件日志，再写内存，即便掉电，也是基本可以从binlog日志中恢复的。
设计一个高吞吐量的服务系统。上述SSD,基本达到了10万/s的随机访问读取小数据块的能力，除去网络层对资源的消耗，索引消耗(10亿 8字节ID索引文件 -
10亿 * （8 + 12） = 20G ，哈希索引,全放内存，time33 hash算法 i5基本可以每秒到1千万）+32G内存 + 1T SSD 可以承载 8万/S ,10亿记录的随机读 ,再一水平分布，X 4 ,32万/s . 再乘以2，每个热.备, 每天8万秒，正常服务时间 6万秒。支撑每天180亿请求的系统就这么出来了. 这180亿/天 可以干嘛，最典型的就是全站用户凭证系统，每个pv都会访问的.
当然这个测试还是比较简单的,, 可以有更多的维度去反映这个读的能力, 比喻统计各个时间段的每周期的处理数曲线，await时间,开启关闭page cache时的 曲线波动情况。启用文件系统的pageCache后,cache满后 pdflush到设备是否会导致当前读的耗时波动过大. 具体波动情况.
还有读写混合时，读写各种比例的情况,有锁 无锁的情况，及锁的粒度对吞吐量及耗时曲线的影响.优秀的存储系统都是需要对这些细节都了如指掌的。
波动是一个很危险的现象,当一个大的波动发生时，在一个小的周期内，系统的吞吐量会迅速下降，如果一旦下降后，产生系统的吞吐量小于最上层用户的请求，那么请求就会积压,积压的时间一长，特别是互联网业务，上层用户的请求很容易发生重试，一旦重试，上层的请求树就会向上波动增长，而系统的吞吐量却在降低(向下波动)，很容易导致请求数持续积压，重试持续增长，系统就崩的下，雪崩了. 说到这里就讲到了 系统过载时的对应了，就需要降级，熔断等措施了 。不发散了. 有时间在另起篇幅来讲讲.
-------ps 写写技术博客的好处，经常会主动思考一些问题，然后把来龙去脉通过各种方式梳理清楚，如有精力和时间，会将细节弄的越细越好. 经常思考一个问题以后，过了若干时间，发现当初思考的不全面或是有误，还可以再继续修改一番。这样感觉很好.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
