寻找专用MySQL服务器的磁盘I / O比较

需要注意的是你的dd命令不会绕过操作系统的文件系统caching。 这意味着您将得到不同的结果，具体取决于正在进行的操作，当您增加输出大小（并因此耗尽您的fscaching）时，您会注意到显着的性能变化。

添加“oflag = direct”来绕过输出文件上的文件系统caching，例如

 time dd if=/dev/zero of=OUT.tmp bs=1M count=1000 oflag=direct 

您可以使用iflag = direct绕过文件系统caching进行读取

而且，你的performance会随着大小的不同而有很大的不同 虽然1M是testing顺序写入的一个相当不错的折衷，但除非您的应用程序正在写出1M个块，否则不会代表您的实际性能。

总的来说，这些吞吐量数据是非常糟糕的 – 单个SATA硬盘（例如Seagate ES.2硬盘）在硬盘启动时可达到105MB / sec的连续写入峰值，并且在硬盘启动时达到60MB / sec整个驱动器。

最后，通用数据库“最佳实践”说，为避免RAID5 / 6作为数据库的底层系统，由于奇偶校验写入造成的开销相对较高（而不是实际的奇偶校验计算本身，硬件上相当便宜，写出新的奇偶校验时必须进行额外的读写操作）。

这是我的MySQL服务器的结果。 这是一个64位，而不是虚拟机，所以不知道它有多less使用，但有一个非常大的差异。

 time dd if=/dev/zero of=OUT.tmp bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 5.72139 s, 183 MB/s 0.00s user 1.55s system 27% cpu 5.725 total time dd if=OUT.tmp of=/dev/null bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 0.432328 s, 2.4 GB/s 0.00s user 0.45s system 103% cpu 0.436 total 

在大多数情况下，你也应该比较随机io [如bonnie ++ ]不仅线性读/写。 或者也许它是一个大的数据接收器需要日志和存储在未索引的巨大表格？

dd'benchmark'的结果

 szcapp1:/mnt/big/tmp# time dd if=/dev/zero of=OUT.tmp bs=1M count=1000 time dd if=OUT.tmp of=/dev/null bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 4.26186 s, 246 MB/s real 0m4.563s user 0m0.001s sys 0m2.255s szcapp1:/mnt/big/tmp# time dd if=OUT.tmp of=/dev/null bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 0.457162 s, 2.3 GB/s real 0m0.459s user 0m0.000s sys 0m0.459s szcapp1:/mnt/big/tmp# 

在戴尔供电2950 64位Linux，PERC6突袭5 5台桌面500GB SATA硬盘。 16GB RAM，2x四核2.66GHz。 但嘿！ 这没有任何意义 – 这个数据适合raid控制器的高速缓冲存储器的1/4，并放在系统内存中。

你的结果确实很慢。 vmware运行在linux上面的结果[vmware server 2.0下的32位linux guest]：

 vfeed0:/tmp# time dd if=/dev/zero of=OUT.tmp bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 15.996 s, 65.6 MB/s real 0m16.043s user 0m0.016s sys 0m13.117s vfeed0:/tmp# time dd if=OUT.tmp of=/dev/null bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 0.49413 s, 2.1 GB/s real 0m0.505s user 0m0.000s sys 0m0.500s vfeed0:/tmp# 

请记住，读取性能是假的 – 从caching中读取 – 如果不是从guest虚拟机的caching中读取的，则从vmware主机的caching中读取。

除了丹尼尔·劳森（Daniel Lawson）关于caching的GB / S结果的logging之外。

如果您的dd不支持iflag/oflag则可以使用以下命令手动刷新磁盘caching：

 sync; echo 3 > /proc/sys/vm/drop_caches 

或者简单地使用一个比你的RAM大两倍的数据集，将确保数据从来没有机会在运行之间被caching。

至于你的顾问的ddtesting – 这是一个很好的起点，但不是一个确定的testing。 它正在测量连续的I / O。 这就是在物理磁盘上紧挨着的读写块。 不幸的是数据库很less处理连续的I / O。 logging在不同的时间被写入，并且通常不会按照写入的顺序随时间被恢复。

考虑到这一点，您需要测量的两个最重要的因素是随机I / O吞吐量和延迟。 这些将对MySQL的行为产生最大的影响。 要衡量这些我会build议使用实用bonnie++ 。 它具有预设的testingfunction，可以对上述所有function进行基准testing，并且如果您想testing特定的方面，则可以进行更多配

您也可以使用MySQL超级testing来衡量单个SQL查询的重复性能。

有点远离你原来的问题; 但是SAN供应商对“RAID 5速度慢”的反应是将其转换为RAID 1或RAID 10.另外，考虑到VMFSalignment（ PDF ）可能会严重影响性能。

当我蹩脚的老戴尔Latitude D520 （80Go; 5400RPM）挑战你的MySQL服务器，你知道有一个地方的问题^^：

 $ time dd if=/dev/zero of=OUT.tmp bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 32.5178 s, 32.2 MB/s real 0m32.662s user 0m0.008s sys 0m2.716s $ time dd if=OUT.tmp of=/dev/null bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 29.8311 s, 35.2 MB/s real 0m29.892s user 0m0.004s sys 0m2.056s 

您应该先看看这两个testing对ESX节点的I / O负载所造成的负担。

然后，在节点和SAN上执行一个Bonnie ++testing，再加上iostat和mpstat并行shell（ahoy screen！），以查找瓶颈位置。 你肯定会在某个地方发现大量的爱荷华州，这将是集中的一部分。