Amazon EC2 Disk Performence

本文的目的是为了测试 Amazon EC2 的磁盘性能，从而为数据库搭建做性能估算。使用的测试工具为 sysbench ，这款软件已经很久没更新了。所以全当得出数据为“比较值”。
Amazon 的 Elastic Storage 为 EC2 Instance 提供了软 Raid 的可能性，但是，其 Raid 除了具有数据保障性外，是否有性能提升？提升多少？这是这次实验的目的。

参考别处资料写了一个 sysbench 测试脚本：

#!/bin/bash
 
set -u
set -x
set -e
for size in 2G 4G 8G;do
for mode in seqwr seqrd seqrewr rndrd rndwr rndrw;do
for blksize in 16384 ; do
sysbench --test=fileio --file-num=32 --file-total-size=$size prepare
for threads in 1 4 8 16 32; do
echo "===== testing $blksize in $ $threads threads"
echo PARAMS $size $mode $threads $blksize > sysbench-size-$size-mode-$mode-threads-$threads-blksz-$blksize
for i in 1 2 3 ; do
sysbench --test=fileio --file-total-size=$size --file-test-mode=$mode --max-time=180 --max-requests=100000000 --num-threads=$threads --init-rng=on --file-num=32 --file-extra-flags=direct --file-fsync-freq=0 --file-block-size=$blksize run | tee -a sysbench-size-$size-mode-$mode-threads-$threads-blksz-$blksize 2>&1
done
done
sysbench --test=fileio --file-total-size=$size cleanup
done
done
done

基础数值

首先，来一款手头上的普通三星 160G 硬盘，将其作为一个参考数值。

Form 1 — fsync at end of test

Form 2 — fsync per write request

一些缩写解释如下：

Req&Trans/s=Request & Transferred/sec
TRD=Threads
SEQ=sequency
RD=read
WR=Write
RND=Random
REWR=Read&Write

你看到的是一块非常普通的硬盘，他的顺序写也只有每秒54M，而现在好一些的硬盘都可以做到每秒80M以上的顺序写了。
来看看 Amazon 的测试数据吧。

Amazon Micro Instance with Single Elastic Storage

Form 3 — fsync at end of test

请注意看红色的部分，Amazon 磁盘的测试结果，写操作差的一塌糊涂，几乎和个U盘一样，但是只要有读操作！尤其是随机读取操作，数据就牛逼的一塌糊涂。其中随机读取最佳成绩为 5452\85M，而单个物理硬盘仅为 115\1.8M 。天壤之别！
而且 RndWr 的写入比 SeqWr 要快了很多，这肯定是因为逻辑磁盘到物理磁盘之间存在数据分片。

猜测：
1.Elastic Storage 和EC2 instance 之间很可能是走网络的。
2.一定有数据冗余机制，但估计不是 RAID。
3.有很大的 cache 在前面。很可能在用 SSD 做 cache。

这测试结果，你说好么，写入速度慢成这样…这鸟样也太过分了一点。你说他差么，随机读牛成这样… 没办法形容了。

Amazon Micro Instance with Raid 0 （2 disk）

Form 4 — fsync at end of test

2 Disks Raid0 几乎和单硬盘没有什么太大变化，SeqWr 的数值全线微幅下降，可能是由于系统做软 Raid，系统层面有所开销所致。RndWr 在 16 线程和 32线程略微高一点。但也不是本质性提升。
RndRW 8、16、32 有明显提高，但是很难判断是某个时间段 Amazon IO 比较空闲所致，还是 Raid0 的帮助。有一种可能是我做 md 的时候使用的默认 chunk 为 64，而 Amazon 本身的 chunk 比 64 大，所以我这么操作以后造成了更加分散的数据分布，所以 RndRW 会略好一点。但也很难解释为什么 RndRd 没有明显高起来。

同时我还做了 6 Disk Raid0 测试，由于数据和 2 Disk 实在是没啥差距，就不贴上来了。
总的感觉 Amazon 上做 Raid 是件无意义的事情。这与国外一个人的测试[ 1 2 ]相去甚远。不止是结论差异，性能也有差异，他在 6 Disk Raid0 的情况下 Seq Input 居然可以走到接近 110M 的速度，但是他的 Rnd Seek 在8Disk 的情况下最高也只走到 4000左右。我怀疑这是 Instance 差异导致，接下来看看 m1.large 的测试数据。

Amazon EC2 m1.large NoRaid

Form 5 — fsync at end of test

Form 6 — fsync every 64 times write(1M)

Form 7 — fsync per write request

Amazon EC2 m1.large 6 Disk Raid 0

Form 8 — fsync per write request

根据这些数据可以得到以下结论：

1. Large 比 Micro 在 IO 方面性能好。
2. RAID 无意义。
3. 瓶颈在连续写。
4. Amazon 机器即使在 fsync per write request 的情况下，随机写也可以达到 1000/s ，而随机读在 5000-6000/s。其随机性能比得上 SSD 了。
5. 由于 MySQL Dirty Page 有两次写，两次写空间为 2M，每写1M sync 一次，所以上面专门有 64 times sync 的测试数据。其连续写数据，我觉得可以做为 Amazon Large MySQL 写入瓶颈数值参考。
6. 不要轻易相信别人的神化！

很多 MySQL 的参数设置还需要结合很多信息才能确定，单靠磁盘监测还不够。以后再开别的文章来探讨吧。

No related posts.