我们的监控系统可以通过以下图表最好地说明这种行为.
在大约11:57,cpu利用率从25％上升到75％.平均负载没有显着变化.
我们运行12个内核的服务器,每个内核有2个超线程.操作系统认为这是24个cpu.
通过每分钟运行/usr/bin/mpstat 60 1来收集cpu利用率数据.所有行和％usr列的数据显示在上面的图表中.我确信这确实显示了每个cpu数据的平均值,而不是“堆积”利用率.虽然我们在图表中看到75％的利用率,但我们看到一个流程显示在顶部使用大约2000％的“堆叠”cpu.
负载平均数每分钟取自/ proc / loadavg.
uname -a给出：
Linux ab04 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
Linux dist是红帽企业Linux服务器版本6.3(圣地亚哥)
我们在机器上负载相当大的情况下运行几个Java Web应用程序,每台机器需要100个请求/秒.
如果我正确地解释cpu利用率数据,当我们有75％的cpu利用率时,这意味着我们的cpu平均在75％的时间内执行一个进程.但是,如果我们的cpu在75％的时间都处于忙碌状态,那么我们不应该看到更高的平均负载吗？当我们在运行队列中只有2-4个作业时,cpu如何忙碌75％？
我们是否正确地解释了我们的数据？什么可以导致这种行为？
解决方法
通常这两个数字的模式彼此相关,但你不能认为它们是相同的. cpu负载率接近0％时(例如,当大量IO数据停留在等待状态时)可能会出现高负载,并且当单线程进程运行时,您可以负载1％和100％的cpu全倾斜.同样在短时间内,您可以看到cpu接近100％,但负载仍然低于1,因为平均指标尚未“赶上”.
我已经看到服务器的负载超过15,000(是的,这不是一个错字)和cpu％接近0％.之所以发生这种情况,是因为Samba共享存在问题,很多客户开始陷入IO等待状态.如果您看到没有相应cpu活动的常规高负载数,则可能存在某种存储问题.在虚拟机上,这也意味着在同一VM主机上存在大量竞争存储资源的其他VM.
