linux – 低负载平均值,但高%用户和%系统CPU使用率

前端之家收集整理的这篇文章主要介绍了linux – 低负载平均值,但高%用户和%系统CPU使用率前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
总结问题:

>为什么我们看到一组服务器在使用与其他服务器相同的数据库和工作负载时表现更差?除了较长的执行时间之外的症状是低(接近零)负载平均,高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核心.

解决方法

我想我知道你在做什么.这是一个可以达到更高cpu利用率同时具有更低负载平均值的方案.虽然老实说cpu占50%应该至少意味着0.5的负载.所以有些事情在你无法控制的范围内出错.

也就是说,请考虑以下因素:

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

2)您的应用程序使用足够的cpu来消耗突发,然后被限制.

3)此节流阀既增加了所使用的cpu百分比,又降低了实际的应用程序吞吐量.

4)减少的应用程序吞吐量意味着较少的相关活动产生(子进程,磁盘写入……),这意味着总体上创建的负载较少.

原文链接:https://www.f2er.com/linux/395814.html

猜你在找的Linux相关文章