感谢分享

看起来我用的硬盘很垃圾啊，浦科特 PX-256M7VC
测试4k Q1T1 才得760，都不上1000
楼主能推荐一下256G的速度快的固态硬盘吗

sairen139 发表于 2019-12-30 16:33
转载文章解惑：SSD的随机读能力 和一个高访问量的读写服务系统  原创jeanter1481次阅读  2016- ...

用CDM测SSD性能，它的4K Q1T1 write为什么比read的分数高
头像
通吃世界 1
2018-10-10
只看楼主
各位大神们，用CDM测SSD性能，它的4K Q1T1 write为什么比read的分数高
2
头像
k627324240 1
12-14 15:25
操作
虽然在挖坟但我还是回复一下吧
4K Q1T1的读取也就是Read部分，读取时因为是单队列单线程随机，无法被与闪存无关的高速缓存预测，每一次读取都是考验闪存+主控的真实随机性能
4K Q1T1的写入也就是Write部分，写入时可以先置于与闪存颗粒无关的高速缓存，因此4K Q1T1 Write是很快的
个人认为的考验SSD的日常性能几个理论数据：
——读写速度数据——
Seq（大量连续读写时的性能参考）
4K Q8T8（重度负载时的性能参考）
4K Q1T1（重要，影响日常体验）
——其它——
响应延迟
唤醒延迟
k627324240: 其中4K Q1T1只要看Read部分就行了，Write部分只要不慢得离谱，是没有实用意义的

转载文章解惑：SSD的随机读能力 和一个高访问量的读写服务系统  原创[size=0.24]

jeanter

[size=0.24]1481次阅读  2016-04-19

[size=0.28][url=]关注[/url]

    昨天晚上写了个代码，测试了下目前我这个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

[color=rgb(34, 34, 34) !important]    然后接USB连一个5400转的机械硬盘随机读1万条，注意是1万，不是100万，花了90s。

    顺序写20G文件, SSD 150MB/s  5400转机械硬盘 80MB/s  ,一倍差距. 所以顺序写文件的10K转速的机械磁盘应该和SSD不分上下的.  基于机械磁盘的这种特点，存储系统中，特别是NoSql的内存数据库，基本会用这类做binlog日志,先写文件日志，再写内存，即便掉电，也是基本可以从binlog日志中恢复的。

设计一个高吞吐量的服务系统。上述SSD,基本达到了10万/s的随机访问读取小数据块的能力，除去网络层对资源的消耗，索引消耗(10亿 8字节ID索引文件 -

[color=rgb(34, 34, 34) !important]10亿  * （8 + 12） = 20G ，哈希索引,全放内存，time33 hash算法 i5基本可以每秒到1千万）+32G内存  + 1T SSD  可以承载  8万/S ,10亿记录的随机读 ,再一水平分布，X 4 ,32万/s .  再乘以2，每个热.备, 每天8万秒，正常服务时间 6万秒。支撑每天180亿请求的系统就这么出来了. 这180亿/天 可以干嘛，最典型的就是全站用户凭证系统，每个pv都会访问的.

[color=rgb(34, 34, 34) !important]    当然这个测试还是比较简单的,, 可以有更多的维度去反映这个读的能力,  比喻统计各个时间段的每周期的处理数曲线，await时间,开启关闭page cache时的 曲线波动情况。启用文件系统的pageCache后,cache满后 pdflush到设备是否会导致当前读的耗时波动过大. 具体波动情况.

[color=rgb(34, 34, 34) !important]   还有读写混合时，读写各种比例的情况,有锁 无锁的情况，及锁的粒度对吞吐量及耗时曲线的影响.优秀的存储系统都是需要对这些细节都了如指掌的。

[color=rgb(34, 34, 34) !important]    波动是一个很危险的现象,当一个大的波动发生时，在一个小的周期内，系统的吞吐量会迅速下降，如果一旦下降后，产生系统的吞吐量小于最上层用户的请求，那么请求就会积压,积压的时间一长，特别是互联网业务，上层用户的请求很容易发生重试，一旦重试，上层的请求树就会向上波动增长，而系统的吞吐量却在降低(向下波动)，很容易导致请求数持续积压，重试持续增长，系统就崩的下，雪崩了. 说到这里就讲到了 系统过载时的对应了，就需要降级，熔断等措施了 。不发散了. 有时间在另起篇幅来讲讲.

[color=rgb(34, 34, 34) !important]-------ps 写写技术博客的好处，经常会主动思考一些问题，然后把来龙去脉通过各种方式梳理清楚，如有精力和时间，会将细节弄的越细越好. 经常思考一个问题以后，过了若干时间，发现当初思考的不全面或是有误，还可以再继续修改一番。这样感觉很好.

文章最后发布于: 2016-04-19

[size=0.24]版权声明：本文为博主原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接和本声明。 本文链接：https://blog.csdn.net/jeanter/article/details/51193038