SAN环境下的MySQL I/O调优_Mysql_Innodb_Query Performance_San

SAN环境下的MySQL I/O调优

mysql

SAN环境下的MySQL I/O调优,mysql,innodb,query-performance,san,Mysql,Innodb,Query Performance,San,我有MySQL MySQL version: 5.6.16-enterprise-commercial-advanced-log MySQL Engine: InnoDB MySQL Data Size: 35GB (including 9GB of indexes) 正在运行的 VM: Red Hat Enterprise Linux Server release 5.9 (Tikanga) File system: ext3 Storage technology: SAN Disk dat

我有MySQL

MySQL version: 5.6.16-enterprise-commercial-advanced-log
MySQL Engine: InnoDB
MySQL Data Size: 35GB (including 9GB of indexes)

正在运行的

VM: Red Hat Enterprise Linux Server release 5.9 (Tikanga)
File system: ext3
Storage technology: SAN
Disk data format: RAID-5
Disk type: SAS with Fibre channel

我发现很多SELECT查询都需要时间，这是因为I/O相关的操作，尽管必要的索引和缓冲区被添加到了同一个查询中

mysql> show profile for query 1;
+----------------------+------------+
| Status               | Duration   |    
+----------------------+------------+
| starting             |   0.000313 |
| checking permissions |   0.000024 |
| checking permissions |   0.000018 |
| Opening tables       |   0.000086 |
| init                 |   0.000121 |
| System lock          |   0.000092 |
| optimizing           |   0.000079 |
| statistics           |   0.000584 |
| preparing            |   0.000070 |
| executing            |   0.000014 |
| Sending data         | 202.362338 |
| end                  |   0.000068 |
| query end            |   0.000027 |
| closing tables       |   0.000049 |
| freeing items        |   0.000124 |
| logging slow query   |   0.000135 |
| cleaning up          |   0.000057 |
+----------------------+------------+

以下网络延迟和吞吐量是否适合上述DB实例

$ time dd if=/dev/zero of=foobar bs=4k count=10000
10000+0 records in
10000+0 records out
40960000 bytes (41 MB) copied, 1.22617 seconds, 33.4 MB/s
real    0m1.233s
user    0m0.002s
sys 0m0.049s

$ time dd if=foobar of=/dev/null bs=4k count=10000
10000+0 records in
10000+0 records out
40960000 bytes (41 MB) copied, 0.026479 seconds, 1.5 GB/s
real    0m0.032s
user    0m0.004s
sys 0m0.024s

$ time dd if=/dev/zero of=foobar bs=128K count=10000
10000+0 records in
10000+0 records out
1310720000 bytes (1.3 GB) copied, 78.1099 seconds, 16.8 MB/s
real    1m18.241s
user    0m0.012s
sys 0m1.117s

$ time dd if=foobar of=/dev/null bs=128K count=10000
10000+0 records in
10000+0 records out
163840000 bytes (164 MB) copied, 0.084886 seconds, 1.9 GB/s
real    0m0.101s
user    0m0.002s
sys 0m0.083s

$ time dd if=/dev/zero of=foobar bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 461.587 seconds, 22.7 MB/s
real    7m42.700s
user    0m0.017s
sys 0m8.229s

$ time dd if=foobar of=/dev/null bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 4.63128 seconds, 2.3 GB/s
real    0m4.634s
user    0m0.003s
sys 0m4.579s

以下对MySQL系统变量的更改是否会在MySQL I/O调优环境中产生积极的结果

innodb_flush_方法：O_DSYNC用于读取繁重的工作负载从ext3移动到XFS文件系统

很难回答您的问题，因为对于性能问题，答案通常是“视情况而定”。对不起

您需要做的第一件事是了解实际发生的情况，以及为什么您的绩效低于预期。有各种各样的工具，特别是在Linux系统上

首先，获取系统读写性能的基准。我倾向于使用的简单测试是对dd计时：

如果可以很快完成，则增加100到1000。这将使您了解存储系统的持续吞吐量

每秒测试IO操作也是一件类似的事情——执行相同的操作，但使用较小的块大小和较大的计数。4k块大小，10000作为计数-同样，如果速度过快，增加数字

这将为您估计存储子系统的IOPs和吞吐量

现在，您还没有明确说明所使用的磁盘类型和心轴数量。根据极其粗略的经验，在性能开始下降之前，SATA驱动器的IOPs应为75，FC或SAS驱动器的IOPs应为150，SSD的IOPs应为1500

但是，当你使用RAID-5时，你需要考虑RAID-5的写入惩罚，这是4。这意味着您的RAID-5需要4次操作才能完成一次写入IO。没有读惩罚，但出于明显的原因，您的“奇偶校验”驱动器不算作主轴

你的工作量看起来怎么样？主要是读，主要是写？眼压多少？有多少纺锤？老实说，问题的根源很可能是对存储子系统的期望