>为什么我们看到一组服务器在使用与其他服务器相同的数据库和工作负载时表现更差？除了较长的执行时间之外的症状是低(接近零)负载平均,高CPU使用率和特别高的系统使用百分比.
详细描述：
我有几个服务器位于托管合作伙伴,运行MySQL 5.1.67和5.1.73,我们在高峰时段观察到性能问题.
我们看到的是负载平均值从通常的水平下降到接近0(0.10-0.20),它可能最好用来自New Relic的图像来描述
如果我在测试和生产服务器上并行运行它,而不是在任何其他服务器上运行它,我可以用捕获的工作负载(以及数据库转储)重现问题.
我已经设置了一个与my.cnf相同的亚马逊实例作为测试(帖子末尾的详细信息),还尝试了我可用的另一台Linux服务器(LXC容器)甚至我的台式机.测试和生产的执行时间为4分钟,其他所有执行时间大约为1分30秒,并且在负载平均值较低但％user和％system为高的情况下不显示此行为.
Vmstat在工作负载运行时显示高运行队列和大量上下文切换,但仅在有问题的机器上,sar显示没有iowait：
测试：
$./workload.sh & vmstat 1 10 -w procs -------------------memory------------------ ---swap-- -----io---- --system-- -----cpu------- r b swpd free buff cache 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 top on Testing: $top top - 19:49:22 up 1 day,1:15,5 users,load average: 0.08,0.10,0.09 Tasks: 607 total,1 running,606 sleeping,0 stopped,0 zombie Cpu(s): 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 on Testing: 08:11:04 PM CPU %user %nice %system %iowait %steal %idle 08:11:05 PM all 51.08 0.00 24.37 0.00 0.00 24.54 08:11:06 PM all 47.14 0.00 26.15 0.00 0.00 26.71
亚马逊：
$./workload.sh & vmstat 1 10 -w [1] 10472 procs -------------------memory------------------ ---swap-- -----io---- --system-- -----cpu------- r b swpd free buff cache 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 top on Amazon: ]$top top - 13:51:09 up 6:12,2 users,load average: 6.72,3.73,1.69 Tasks: 256 total,6 running,250 sleeping,0 zombie Cpu(s): 68.8%us,7.5%sy,23.6%id,0.0%st
服务器：
>生产：运行5.1.67,RedHat 6.4的MySQL slave(只读). 2 x 6核心Xeon(R)CPU E5-2630L 0 @ 2.00GHz,带超线程,192GB内存(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)
此外,我们还有以下内容,我没有看到问题,并且在1m30sec内执行工作负载,而上述两种情况则为4min：
> Amazon：MySQL 5.1.73,c4x2large RedHat 6.5 – 使用sysctl.conf和my.cnf从Testing服务器配置.
> LXC：MySQL 5.1.73,CentOS6,my.cnf来自测试
>我的桌面：MariaDB 5.5,Ubuntu,i7 4核心.
解决方法
也就是说,请考虑以下因素：
1)虚拟服务器具有类似于Amazon EC2微实例的突发/限制CPU分配方案.
2)您的应用程序使用足够的CPU来消耗突发,然后被限制.
3)此节流阀既增加了所使用的CPU百分比,又降低了实际的应用程序吞吐量.
4)减少的应用程序吞吐量意味着较少的相关活动产生(子进程,磁盘写入……),这意味着总体上创建的负载较少.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。