ucloud的rssd性能测试

发表于 更新于 分类于 本文字数： 2.1k 阅读时长 ≈ 2 分钟

在公有云中存储和网络是最重要的部分。非常考验技术水平的。

国内云盘宣称可以跑到4GB的有阿里云的essd和ucloud的rssd。 其他华为云和腾讯云现在只能到750MB

下面是2家各自的帮助页面
https://docs.ucloud.cn/uhost/introduction/disk

https://help.aliyun.com/document_detail/25382.html

两家表面的参数是差不多的，但是ucloud是没有数据可靠性的。标称的参数rssd比essd还高出了20%。

两家都是推荐16核CPU以上的服务器使用才能达到最佳性能。

单价的话阿里云essd PL3单价是4元/GB，ucloud的rssd是0.6元/GB

我们是fio进行了如下的测试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
### 随机写
fio -direct=1 -iodepth=64 -rw=randwrite -ioengine=libaio -bs=4k -size=4G -numjobs=1 -runtime=1000 -group_reporting -filename=iotest -name=Rand_Write_Testing

### 随机读
fio -direct=1 -iodepth=64 -rw=randread -ioengine=libaio -bs=4k -size=4G -numjobs=1 -runtime=1000 -group_reporting -filename=iotest -name=Rand_Read_Testing

### 随机写吞吐
fio -direct=1 -iodepth=64 -rw=randwrite -ioengine=libaio -bs=16k -size=4G -numjobs=1 -runtime=1000 -group_reporting -filename=iotest -name=Write_PPS_Testing

### 随机读吞吐
fio -direct=1 -iodepth=64 -rw=randread -ioengine=libaio -bs=16k -size=4G -numjobs=1 -runtime=1000 -group_reporting -filename=iotest -name=Write_PPS_Testing

### 随机写延迟
fio -direct=1 -iodepth=64 -rw=randwrite -ioengine=libaio -bs=4k -size=4G -numjobs=1 -group_reporting -filename=iotest -name=Rand_Write_Latency_Testing

### 随机读延迟
fio -direct=1 -iodepth=64 -rw=randread -ioengine=libaio -bs=4k -size=4G -numjobs=1 -group_reporting -filename=iotest -name=Rand_Read_Latency_Testing

这里的吞吐使用了16K的block size，其他都是4K，测试的rssd的大小都是2040GB，本来想2048GB，结果无法选择。

按照ucloud的标称来看，这个盘的iops是103800，吞吐是1140GB。

1
2
IOPS = 2040 * 50 + 1800 = 103800
wMB =  2040 * 0.5 + 120 = 1140.0

但是ucloud比较诡异的是这里写的是顺序读写，正常来说ssd磁盘的顺序和随机读写是差不了多少的。

下面就是针对ucloud rssd的一个具体测试数据

机器配置 随机写IOPS 随机读IOPS 随机写吞吐 随机读吞吐 随机写延迟 随机读延迟
2核4G 37.8k 37.0k 157MB/s 157MB/s 1682.79us 1683.66us
4核8G 53.7k 74.0k 315MB/s 315MB/s 853.09us 852.14us
8核16G 45.8k 104k 629MB/s 629MB/s 615.58us 615.30us
16核32G 104k 104k 1194MB/s 1195MB/s 615.57us 615.52us
32核64G 104k 104k 1195MB/s 1195MB/s 615.79us 615.27us

这里8核16G的时候随机写的IOPS比较奇怪，然后基本到了16核32G就可以到了标称容量的上限了。

但是我又改了下fio测试参数，将numbjobs从1改成了32，在32核的机器上再跑了一遍测试

机器配置 随机写IOPS 随机读IOPS 随机写吞吐 随机读吞吐 随机写延迟 随机读延迟
32核64G 104k 104k 1195MB/s 1195MB/s 19661.38us 19683.28us

可以看到，由于io的读写线程数的增加，导致读写延迟出现了较大幅度的增加。这个是由于线程之间的争抢导致的？