☰

测试：

tag-icon • tag-icon linux mysql
测试：

总结一下问题：

  • 为什么我们发现一组服务器在数据库和工作负载相同的情况下性能明显低于其他服务器？除了执行时间较长之外，其他症状还包括平均负载较低（接近于零）、CPU 使用率较高，特别是系统使用率较高。

详细描述：我在托管合作伙伴处有几台服务器，运行 MySQL 5.1.67 和 5.1.73，我们在高峰时段观察到性能问题。

我们看到的是平均负载从正常水平下降到接近 0（0.10-0.20），也许用 New Relic 的这张图片可以最好地描述这一点

在此处输入图片描述

如果我在我们的测试和生产服务器上足够并行地运行它，我可以使用捕获的工作负载（和数据库转储）重现该问题，但不能在任何其他服务器上重现。

我已经设置了一个与测试相同的 my.cnf 的 Amazon 实例（详细信息见文章末尾），并且还在另一台可用的 Linux 服务器（LXC 容器）甚至我的台式电脑上进行了尝试。测试和生产上的执行时间为 4 分钟，而其他所有操作大约需要 1 分 30 秒，并且没有显示此行为，其中平均负载较低但 %user 和 %system 较高。

Vmstat 显示在工作负载运行时，运行队列很高，上下文切换次数很多，但仅在有问题的机器上，sar 没有显示 iowait：

测试：

$ ./workload.sh & vmstat 1 10 -w
进程 -------------------内存------------------ ---交换-- -----io---- --系统-- -----cpu-------
 rb swpd 免费 buff 缓存 si so bi bo in cs us sy id wa st
1 0 168896 3218240 447004 12226164 0 0 9 75 19 12 3 1 97 0 0
32 0 168896 3129304 447004 12226204 0 0 32 0 22669 357979 49 23 27 0 0
29 0 168896 3129112 447004 12226212 0 0 0 40 23365 422537 49 26 25 0 0
14 0 168896 3126188 447004 12226232 0 0 0 52 22386 456626 43 27 30 0 0
29 0 168896 3130980 447012 12226204 0 0 0 68 23028 459332 45 27 29 0 0
24 0 168896 3125212 447020 12239788 0 0 0 96 22968 367447 49 24 27 0 0
27 0 168896 3104804 447020 12259820 0 0 0 68 22830 406129 50 28 22 0 0
30 0 168896 3081740 447020 12280300 0 0 0 0 22493 423641 49 29 22 0 0

测试顶部：
$ 顶部
顶部 - 19:49:22 启动 1 天，1:15，5 个用户，平均负载：0.08、0.10、0.09
任务：总计 607 个，其中 1 个正在运行，606 个正在休眠，0 个已停止，0 个僵尸
CPU：43.7％us，18.0％sy，0.0％ni，38.3％id，0.0％wa，0.0％hi，0.0％si，0.0％st

sar 关于测试：
下午 08:11:04 CPU ％用户％nice％系统％iowait％steal％idle
08:11:05 PM 全部 51.08 0.00 24.37 0.00 0.00 24.54
08:11:06 PM 全部 47.14 0.00 26.15 0.00 0.00 26.71

亚马逊：

$ ./workload.sh & vmstat 1 10 -w
[1] 10472
进程 -------------------内存------------------ ---交换-- -----io---- --系统-- -----cpu-------
 rb swpd 免费 buff 缓存 si so bi bo in cs us sy id wa st
 6 0 0 14133876 30316 90372 0 0 1 1 58 79 2 0 98 0 0
14 0 0 14090268 30316 95972 0 0 0 0 16866 27910 88 10 3 0 0
34 0 0 13910708 30324 90372 0 0 0 192 13934 25824 86 9 5 0 0
 1 0 0 14079724 30332 90372 0 0 0 228 10041 8075 31 2 67 0 0
 2 0 0 14102296 30332 90372 0 0 0 0 10129 7601 14 2 84 0 0
28 0 0 14095320 30332 92020 0 0 0 0 19820 27951 76 8 16 0 0
32 0 0 13940612 30340 91256 0 0 0 144 20896 26666 83 11 6 0 0
 1 0 0 14068780 30348 90372 0 0 0 204 13971 13457 53 4 42 0 0
26 0 0 14068696 30356 92816 0 0 0 56 18661 24165 65 8 26 0 0
16 0 0 13997072 30372 101740 0 0 0 288 14984 23034 63 9 26 2 0

亚马逊排名前列：

]$ 顶部
顶部 - 13:51:09 启动 6:12，2 个用户，平均负载：6.72、3.73、1.69
任务：共 256 个，其中 6 个正在运行，250 个正在休眠，0 个已停止，0 个僵尸
CPU：68.8％us，7.5％sy，0.0％ni，23.6％id，0.0％wa，0.0％hi，0.0％si，0.0％st

服务器：

  • 生产：MySQL 从属（只读）运行 5.1.67、RedHat 6.4。2 x 6 核 Xeon(R) CPU E5-2630L 0 @ 2.00GHz，带超线程，192GB RAM（128GB innodb_buffer）

  • 测试：MySQL 5.1.73、RedHat 6.5（最近更新以查看是否能解决问题）。2 x 6 核 Xeon(R) CPU E5-2630L 0 @ 2.00GHz，带超线程，32GB 内存（4192M innodb_buffer）

此外，我们还有以下内容，我没有看到问题，并且在 1 分 30 秒内执行了工作负载，而上面两个则需要 4 分钟：

  • 亚马逊：MySQL 5.1.73、c4x2large RedHat 6.5 - 从测试服务器配置了 sysctl.conf 和 my.cnf。

  • LXC：MySQL 5.1.73，CentOS6，my.cnf 来自测试

  • 我的桌面：MariaDB 5.5、Ubuntu、i7 4 核。

答案1

我想我知道你的意思。这是一个可以实现更高的 CPU 利用率同时降低平均负载的场景。虽然说实话，CPU 处于 50% 应该至少意味着负载为 0.5。因此，有些事情超出了你的控制范围。

话虽如此，请考虑以下几点：

1)虚拟服务器具有类似于Amazon EC2微实例的突发/限制CPU分配方案。

2) 您的应用程序使用了足够的 CPU 来耗尽突发量，然后受到限制。

3) 此限制既增加了感知的 CPU 使用百分比，同时又降低了实际的应用程序吞吐量。

4)应用程序吞吐量降低意味着产生的相关活动（子进程、磁盘写入等）减少，从而意味着总体产生的负载减少。

相关内容