为什么尽管CPU或磁盘都没有过度使用,但负载仍然很高


20

我从得到以下输出top

Cpu(s): 43.8%us, 32.5%sy,  4.8%ni,  2.0%id, 15.6%wa,  0.2%hi,  1.2%si,  0.0%st
Mem:  16331504k total, 15759412k used,   572092k free,  4575980k buffers
Swap:  4194296k total,   260644k used,  3933652k free,  1588044k cached

来自的输出iostat -xk 6显示以下内容:

Device: rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda       0.00   360.20   86.20  153.40  1133.60  2054.40    26.61     1.51    6.27   0.77  18.38
sdb       0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdd      22.60   198.80   17.40   31.60   265.60   921.60    48.46     0.18    3.70   1.67   8.20
sdc      16.80   218.20   22.20   23.40   261.60   966.40    53.86     0.21    4.56   1.49   6.78

根据以上所述,似乎必须重载某些内容。但是呢

问题

  1. 如果不是硬盘或CPU,那又如何呢?
  2. 似乎等待时间花费了CPU的15.6%。它到底在等待什么呢?

2
什么是cpu规格,负载是多少?
sepehr 2014年

负载超过100
2014年

负载相对于cpu和cpu内核的数量,系统的cpu规格是什么?
sepehr 2014年

Answers:


49

作为一个澄清点,负载并不直接与CPU相关。这是关于负载的最常见的误解之一。您提到磁盘的事实似乎承认您已经意识到了这一点,但是我只想提及它,因为我看到一些注释表明有人反对。

负载定义为等待系统资源的进程数。通常是CPU,磁盘或网络,但实际上可以是任何硬件。
“过程”也不一定是完整过程。线程被定义为“轻量级进程”,并且每个正在等待的线程都会增加负载计数。


要找出哪些过程是问题:

运行top -H-H启用显示线程)

键盘快捷键因版本而异。

使用较新的top(3.3及更高版本):

按调f出字段选项。
使用箭头键转到,S = Process Status然后按s
按下q可返回主页。
Shift+ R反转排序。

使用较旧的顶部(3.3之前):

Shift+调o出排序选项。
然后w按进程状态排序。
然后Enter返回主页。
然后Shift+ R反转排序。

然后在该S列中,查找具有DR(现在应该在顶部)的进程。这些将是导致系统负载的过程。

如果该过程显示D,则表示“不间断睡眠”。通常,这是由于进程在I / O(磁盘,网络等)上等待而引起的。
如果该过程显示为R,则表示它只是在进行正常的计算。


要了解有关这些流程在做什么的更多信息:

使用较新的top(3.3及更高版本):

按调f出字段选项。
使用箭头键转到WCHAN = Sleeping in Function并按d启用它。
然后q返回主页。

使用较旧的顶部(3.3之前):

按下f然后y启用WCHAN场。

如果您的系统具有必要的内核选项,并且系统上存在wchan文件(我忘记了它的位置和名称),则该WCHAN字段应向您显示进程当前正在运行的内核功能(如果该字段仅显示一个-?在所有方面都没有支持)。
一点谷歌在这里,你应该在路上。

如果您没有技术支持,则可以随时尝试strace在流程中找出它们在做什么,但这是困难的方法。


我通常只需按左箭头即可更改排序。
Nemo

2

诸如编译作业或循环中失败的进程之类的寿命短的进程通常在诸如topiostat之类的监视工具中不可见。

在这种情况下,Linux Audit Framework将有所帮助

罪魁祸首,例如一个失败循环

while :; do gcc /dev/zero ; done >/dev/null 2>&1

要使用auditd / auditctl:

apt-get install auditd
auditctl -a task,always
ausearch -i -sc execve

日志中窃取的所有进程启动


如果它们未出现在中top,则它们不太可能有助于平均负载。为了使其有助于平均负载,它必须长时间处于等待状态。从统计上讲,这意味着它将显示在中top。如果不是,那么它就不是重要的贡献者。
Patrick

0

我遇到了NFS挂载断开连接的情况,不幸的是我犯了一个错误并且没有使用软挂载选项,因此很多进程都在我的Linux服务器上停滞了,包括监视,lsof甚至bash会话。

卸下坏掉的安装架后,系统看起来超载了:

top - 00:03:48 up 15 days, 14:56,  3 users,  load average: 29, 21, 20

这看起来很糟糕,但是CPU使用率不到15%,并且没有磁盘I / O。我有一些建议可以通过ps进行,但是这似乎对进程几乎处于休眠状态没有帮助。

然后让man ps我整夜不眠,经过调查,我发现要查看的状态标志非常重要,后来发现它们是卡住的进程。

执行:

ps -e v

并在STAT列中查找具有D或的进程SL。这些就像僵尸进程,但未标识为Z僵尸。

D-主要表示磁盘(I / O)活动,但是如果您运行ps -e v几次并且也iostat 3看不到任何活动,则表明这是I / O卡住的状态

SL-这意味着该进程在内存中有“锁定”页面,因此,如果您可以确定该进程的行为不应该如此,那么它可以长期坚持下去而无需更改,这是下一个可能的选择。

经过调查后,我一个又一个地杀死了我,系统平均负载恢复正常。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.