主页 / server / 问题 / 38447
In Process
Brent
Asked: 2009-07-10 08:55:25 +0800 CST

查找专用 MySQL 服务器的磁盘 i/o 比较

  • 772

我们聘请了一位顾问来帮助我们增加 MySQL 集群的容量，他做的第一件事（几乎唯一的一件事）就是测量我们服务器的磁盘 i/o 速度。

我对类似系统上的磁盘 i/o 与我们现有的比较感兴趣：

  • 我们的 MySQL 服务器是运行在具有 SCSI SAN (Raid 5) 的 32 位 VMWare ESX 3.5 上的虚拟服务器，虚拟服务器本身运行 Debian Etch 和 MySQL 5.0.32 版

在 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, 71.3347 seconds, 14.7 MB/s
real    1m13.596s
user    0m0.052s
sys 0m56.932s

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, 21.8202 seconds, 48.1 MB/s
real    0m21.902s
user    0m0.012s  
sys 0m7.948s

这些结果真的“非常慢”吗？

我有兴趣比较其他人在他们的专用 MySQL 机器上从这两个命令获得的结果——特别是如果它是 32 位虚拟机。

performance mysql performance-tuning

6 个回答

  1. 需要注意的是，您的 dd 命令不会绕过操作系统的文件系统缓存。这意味着您将获得不同的结果，具体取决于其他情况，并且随着输出大小的增加（并因此耗尽 fs 缓存），您会注意到显着的性能变化

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

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

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

    此外，您的性能将随块大小而有很大差异。虽然 1M 是测试顺序写入的一个很好的折衷方案，但除非您的应用程序正在写入 1M 块，否则它并不能代表您的实际性能。

    一般来说，这些吞吐量数据非常糟糕 - 单个 sata 驱动器（例如 Seagate ES.2 驱动器）在驱动器启动时可以达到 105MB/秒的峰值顺序写入，并且将维持约 60MB/秒。整个驱动器。

    最后，一般数据库“最佳实践”说要避免将 RAID5/6 作为数据库的底层系统，因为奇偶校验写入导致的开销相对较高（不是实际的奇偶校验计算本身，这在硬件上相当便宜，但效果写出新奇偶校验时必须进行额外的读取和写入）。

    • 3

  2. 这是我的mysql服务器的结果。它是 64 位的，不是虚拟机，所以不确定它到底有多少用处，但有很大的不同。

    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
    • 1

  3. 在大多数情况下，您还应该比较随机 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#

    戴尔 poweredge 2950 上的 64 位 linux，5x 桌面 500GB sata 磁盘上的 perc6 raid 10。16GB 内存，2x 四核 2.66GHz。但是，嘿！这没有任何意义——这些数据在 RAID 控制器的高速缓存内存中占 1/4，而其余的则在系统内存中。

    你的结果确实很慢。vm 在上面的 linux 上运行的结果 [vmware server 2.0 下的 32bit 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#

    请记住，读取性能是假的-它是从缓存中读取的-如果不是从来宾的缓存中读取，则从vmware主机的缓存中读取。

    • 1

  4. 除了 Daniel Lawson 提到的关于缓存 GB/s 结果的内容。

    如果您dd碰巧不支持，iflag/oflag那么您可以使用以下命令在运行之间手动刷新磁盘缓存：

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

    或者简单地使用两倍于 RAM 的数据集将确保数据在运行之间永远没有机会被缓存。

    至于你的顾问的dd测试 - 这是一个很好的起点，但不是一个决定性的测试。它正在测量顺序 I/O。那是物理磁盘上紧挨着的读写块。不幸的是，数据库很少处理顺序 I/O。记录在不同的时间被写入，并且随着时间的推移，通常不会按照写入的顺序进行检索。

    考虑到这一点，您需要测量的两个最重要的因素是随机 I/O 吞吐量和延迟。这些将对 MySQL 的行为方式产生最大的影响。要测量这些，我建议使用该实用程序bonnie++。它具有预设测试来对上述所有内容进行基准测试，如果您想测试特定方面，它的可配置性要高得多。

    您还可以使用MySQL super-smack来衡量单个 SQL 查询的重复性能。

    • 1

  5. 与您最初的问题有些不同；但 SAN 供应商对“RAID 5 很慢”的响应是转换为 RAID 1 或 RAID 10。还要考虑 VMFS 对齐 ( PDF ) 可能会严重影响性能。

    • 0

  6. 当我糟糕的旧戴尔 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

    您应该首先了解这两个测试对 ESX 节点的 I/O 负载造成的压力。

    然后做一个 bonnie++ 测试，并结合 iostat 和 mpstat 在这些节点和 SAN 上以并行 shell（ahoy screen ！）运行，以找出瓶颈所在的位置。你肯定会在某个地方找到大量的 iowait，这将是需要关注的部分。

    • 0

相关问题