7

我的 MySQL 应用程序在运行一些,和查询时遇到性能下降的问题。在这个问题中，我将只讨论一个特定的 ，因为它足以证明问题：UPDATEINSERTDELETEUPDATE

UPDATE projects SET ring = 5 WHERE id = 1

这UPDATE通常足够快，大约 0.2 毫秒，但时不时地（足以成为问题）需要几秒钟。这是日志的摘录（查看第 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以上是在事务的上下文中执行的。服务器上的其他信息：

  • 具有 4GB RAM（原为 1GB）、12GB 可用磁盘空间的 VPS
  • CentOS 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
  • 从默认增加到600Minnodb_buffer_pool_size再增加到 3000M
  • innodb_log_file_size从默认增加到128M
  • 从源代码编译 MySQL
  • Running SHOW PROCESSLIST，它告诉我状态正在“更新”
  • Running 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，除了租用专用服务器之外，我还有什么可以尝试的吗？

4

4 回答 4

2

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

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

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

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

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

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

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

首先，这是前 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提出的测试用例，似乎更新不同的行而不是相同的行确实有一点帮助，但并不能解决问题。

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

谢谢大家的意见。

于 2012-03-14T03:44:35.873 回答
1

当您在云中托管 VPS 时，您可能会遇到完全无法控制的问题。

VPS 受运行它们的主机服务器的随意性影响。例如，Rackspace 云中的 CPU 周期优先级根据 VPS 的大小进行加权。您的 VPS 越大，您的应用程序运行顺畅的可能性就越大。如果您正在使用的主机上有更大的 VPS，则可能是加权突发事件。这很难说。

您是否尝试过在您自己的机器上本地运行它？如果它在您自己的系统上完美运行，并且您需要有保证的性能，那么您最好的选择是迁移到专用服务器。

于 2012-03-13T06:38:57.283 回答
1

你有一个与 VPS 相关的 IO 问题。这不是 MySQL 的错。

您是否有机会将 Elastic Block Store 与 Amazon 或 RDS 一起使用？两者都使用远程存储，以及与存储通信的 IP 协议层；他们有时可能会有严重的滞后。

于 2012-03-13T17:53:31.103 回答
0

问题 1) 是的。

要检查它，请编写 2 个应用程序：

测试用例 1：每分钟都会这样做几个小时

UPDATE `projects` SET `ring` = 5 WHERE `id` = 1
UPDATE `projects` SET `ring` = 6 WHERE `id` = 1

测试用例 2：每分钟都会这样做几个小时

UPDATE `projects` SET `ring` = 7 WHERE `id` = 1
UPDATE `projects` SET `ring` = 8 WHERE `id` = 2

测试用例 1 应该有延迟，而测试用例 2 应该没有。

问题 2) 使用 noSQL 数据库。

于 2012-03-12T21:15:17.453 回答