I/O延迟会导致简单的UPDATE在MySQL中占用几秒钟吗？

Question

我的MySQL应用程序遇到性能降低运行时的一些UPDATE,INSERT和DELETE查询.在这个问题中,我只讨论一个特定问题UPDATE,因为它足以证明问题:

UPDATE projects SET ring = 5 WHERE id = 1

这UPDATE通常足够快,大约0.2ms,但是时不时(足以成为一个问题)需要几秒钟.这是日志的摘录(见第4行):

 ~ (0.000282) UPDATE `projects` SET `ring` = 5 WHERE `id` = 1
 ~ (0.000214) UPDATE `projects` SET `ring` = 6 WHERE `id` = 1
 ~ (0.000238) UPDATE `projects` SET `ring` = 7 WHERE `id` = 1
 ~ (3.986502) UPDATE `projects` SET `ring` = 8 WHERE `id` = 1
 ~ (0.000186) UPDATE `projects` SET `ring` = 9 WHERE `id` = 1
 ~ (0.000217) UPDATE `projects` SET `ring` = 0 WHERE `id` = 1
 ~ (0.000162) UPDATE `projects` SET `ring` = 1 WHERE `id` = 1

projects是一个InnoDB表的类型6列INT和VARCHAR17行和一个索引id.它也发生在其他表中,但在这里我专注于这一个.在尝试解决问题时,我确保查询都是顺序的,因此这不是锁定问题.在UPDATE上述在事务的上下文中执行.服务器上的其他信息:

• VPS具有4GB RAM(1GB),12GB可用磁盘空间
• CentoOS 5.8(原为5.7)
• MySQL 5.5.10(5.0.x)

上面的"是"位意味着它在升级之前或之后不起作用.

到目前为止我尝试了什么,但无济于事:

• 设置innodb_flush_log_at_trx_commit为0,1或2
• 设置innodb_locks_unsafe_for_binlog开启或关闭
• 设置timed_mutexes开启或关闭
• innodb_flush_method从默认值更改为O_DSYNC或O_DIRECT
• 增加innodb_buffer_pool_size从默认到600M再到3000M
• 增加innodb_log_file_size从默认到128M
• 从源代码编译MySQL
• 跑步SHOW PROCESSLIST,告诉我状态是"更新"
• 运行SHOW PROFILE ALL,这表示几乎所有的时间花在"更新"上,并且在这一步骤中,没有那么多时间花在CPU周期上,并且有许多自愿上下文切换(如30)
• 监控SHOW STATUS变化Innodb_buffer_pool_pages_dirty.刷新的脏页和慢查询之间可能存在某种关系,但相关性不明确.

然后我决定检查系统的I/O延迟ioping.这是我的第一个VPS,所以我很惊讶地看到这个结果:

4096 bytes from . (vzfs /dev/vzfs): request=1 time=249.2 ms
4096 bytes from . (vzfs /dev/vzfs): request=2 time=12.3 ms
4096 bytes from . (vzfs /dev/vzfs): request=3 time=110.5 ms
4096 bytes from . (vzfs /dev/vzfs): request=4 time=232.8 ms
4096 bytes from . (vzfs /dev/vzfs): request=5 time=294.4 ms
4096 bytes from . (vzfs /dev/vzfs): request=6 time=704.7 ms
4096 bytes from . (vzfs /dev/vzfs): request=7 time=1115.0 ms
4096 bytes from . (vzfs /dev/vzfs): request=8 time=209.7 ms
4096 bytes from . (vzfs /dev/vzfs): request=9 time=64.2 ms
4096 bytes from . (vzfs /dev/vzfs): request=10 time=396.2 ms

我会说,非常不稳定.

说完所有这些后,我问:

1. I/O延迟偶尔会破坏MySQL的性能吗？我一直认为,当你运行一个时UPDATE,处理该连接的线程不会将数据刷新到磁盘或等待这样的刷新; 它会立即返回,并且在另一个时间由另一个线程完成刷新.

2. 如果它不能是磁盘I/O,除了租用专用服务器之外还有什么我可以尝试的吗？

Answer 1

我正在用根据您的回答收集的附加数据来回答我自己的问题。

我使用了通过无线网络连接的两台笔记本电脑。在笔记本 A 上，我使用 挂载了笔记本 B 的目录sshfs。然后在笔记本 AI 上启动 MySQL，并将该安装目录指定为其数据目录。这应该为 MySQL 提供一个非常慢的 I/O 设备。MySQL 是从 innodb_flush_log_at_trx_commit = 0.

我定义了 3 组查询，每组包含重复 10,000 次的更新和选择查询，没有显式事务。实验是：

• US1SID：更新并选择同一表的特定行。所有迭代中都使用同一行。
• US1MID：更新并选择同一表的特定行。每次迭代中该行都是不同的。
• US2MID：更新和选择不同表的行。在这种情况下，选择读取的表在实验过程中根本没有改变。

每组使用 shell 脚本运行两次（因此计时比我原来问题中的慢），一次在正常条件下运行，另一次在执行以下命令后运行：

tc qdisc replace dev wlan0 root handle 1:0 netem delay 200ms

上面的命令在通过 wlan0 传输数据包时增加了 200ms 的平均延迟。

首先，这是前 99% 最快更新和选择以及后 1% 更新和选择的平均时间。

          |        Delay: 0ms        |       Delay: 200ms       |
          | US1SID | US1MID | US2MID | US1SID | US1MID | US2MID |
| top99%u | 0.0064 | 0.0064 | 0.0064 | 0.0063 | 0.0063 | 0.0063 |
| top99%s | 0.0062 | 0.0063 | 0.0063 | 0.0062 | 0.0062 | 0.0062 |
| bot01%u | 1.1834 | 1.2239 | 0.9561 | 1.9461 | 1.7492 | 1.9731 |
| bot01%s | 0.4600 | 0.5391 | 0.3417 | 1.4424 | 1.1557 | 1.6426 |

很明显，即使 I/O 性能非常非常差，MySQL 也能非常快地执行大多数查询。但我最关心的是最坏的情况，所以这里有另一个表，显示了 10 个最慢的查询。“u”表示这是更新，“s”表示选择。

|          Delay: 0ms         |          Delay: 200ms          |
| US1SID  | US1MID  | US2MID  | US1SID   | US1MID   | US2MID   |
| 5.443 u | 5.946 u | 5.315 u | 11.500 u | 10.860 u | 11.424 s |
| 5.581 u | 5.954 s | 5.466 u | 11.649 s | 10.995 u | 11.496 s |
| 5.863 s | 6.291 u | 5.658 u | 12.551 s | 11.020 u | 12.221 s |
| 6.192 u | 6.513 u | 5.685 u | 12.893 s | 11.370 s | 12.599 u |
| 6.560 u | 6.521 u | 5.736 u | 13.526 u | 11.387 u | 12.803 u |
| 6.562 u | 6.555 u | 5.743 u | 13.997 s | 11.497 u | 12.920 u |
| 6.872 u | 6.575 u | 5.869 u | 14.662 u | 12.825 u | 13.625 u |
| 6.887 u | 7.908 u | 5.996 u | 19.953 u | 12.860 u | 13.828 s |
| 6.937 u | 8.100 u | 6.330 u | 20.623 u | 14.015 u | 16.292 u |
| 8.665 u | 8.298 u | 6.893 u | 27.102 u | 22.042 s | 17.131 u |

结论：

1. 糟糕的 I/O 性能确实会让 MySQL 慢得像爬行一样。目前尚不清楚为什么 或具体何时发生，但它确实发生了。

2. 速度减慢适用于选择和更新，其中更新受到的影响更大。

3. 由于某种原因，即使是未涉及任何更改且最近已填充的表上的选择也会减慢，从上面的 US2MID 可以清楚地看出。

4. 至于mentatkgs提出的测试用例，似乎更新不同的行而不是相同的行确实有一点帮助，但并不能解决问题。

我想我要么调整我的软件以容忍这种延迟，要么尝试转向另一个提供商。对于这个项目来说，租用专用服务器太昂贵了。

谢谢大家的评论。