SSD的随机读能力 和一个高访问量的读写服务系统
来源:互联网 发布:java整型数组转字符串 编辑:程序博客网 时间:2024/06/03 22:42
主机配置 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 写写技术博客的好处,经常会主动思考一些问题,然后把来龙去脉通过各种方式梳理清楚,如有精力和时间,会将细节弄的越细越好. 经常思考一个问题以后,过了若干时间,发现当初思考的不全面或是有误,还可以再继续修改一番。这样感觉很好.
- SSD的随机读能力 和一个高访问量的读写服务系统
- 高访问量系统的解决方案
- Linux系统中使用 DD 命令测试 USB 和 SSD 硬盘的读写速度
- Linux系统中使用 DD 命令测试 USB 和 SSD 硬盘的读写速度
- 高并发高访问量网站的优化
- 高并发高访问量网站的优化
- 高并发高访问量网站的优化
- 高访问量系统解决方案
- 页面访问量和网站访问量的统计
- 【转】大访问量系统的设计——高并发高流量网站架构
- 在开发高访问量、高负载的系统时要注意什么?
- 在开发高访问量、高负载的系统时要注意什么?
- 转】大访问量系统的设计(二)——高并发高流量网站架构
- 【转】大访问量系统的设计(二)——高并发高流量网站架构
- 大访问量系统的设计
- 告诉你如何设计一个日访问量千万级别的系统,谈oracle的高级设计和开发(6)
- 文件的随机读写
- JSP高访问量下的计数程序
- 设计模式(一):单例模式
- 在 Visual C# 中,模拟登录界面与主窗体的交互
- 第七周 项目二
- dispatcher:一个简单的MVC框架或者不能算是MVC 作用
- HDU Labyrinth DP
- SSD的随机读能力 和一个高访问量的读写服务系统
- CSDN自动评论返积分工具
- JavaScript数组与对象(1)
- 第三周项目二本月有几天
- solr入门之自定义排序之构建自己的权重计算方法及相应的排序字段
- 我的第一个博客
- flask 及 python如何发163邮件
- 二叉树中序递归、非递归遍历
- HDU1108 欧几里得