☰

ps 返回 %cpu 和 cputime 不合理的高值

tag-icon • tag-icon linux ps
ps 返回 %cpu 和 cputime 不合理的高值

我们的一台服务器上的 Nagios 发出了一条警报，称有一个进程失控。登录并运行后，top并没有发现任何异常情况，但当我查看 ps 的输出时，我发现了一些奇怪的现象：

oxygen@mail-1:~$ ps -e -o %cpu,comm,cputime --sort %cpu | tail
 0.2 amavisd         00:00:11
 0.2 zmlogger        00:00:54
 0.2 zmstat-allprocs 03:44:19
 0.2 amavisd         00:00:07
 0.2 amavisd         00:00:14
 0.3 amavisd         00:00:08
 0.3 top             00:00:05
 0.5 amavisd         00:00:04
 8.1 mysqld          3-23:07:17
 7413 java            1184016091-02:47:13

％中央处理器和CPU时间看起来不合理。有什么想法可以解释为什么会出现这种情况吗？

oxygen@mail-1:~$ ps --version
procps version 3.2.8
oxygen@mail-1:~$ uname -a
Linux mail-1 2.6.32-35-server #78-Ubuntu SMP Tue Oct 11 16:26:12 UTC 2011 x86_64 GNU/Linux

编辑：回复以下评论：

是的，猜测这是一个 Zimbra 服务器。

平均负载相当高，该服务器受磁盘限制：

top - 09:55:06 up 71 days,  3:23,  1 user,  load average: 4.03, 3.82, 3.60
Tasks: 301 total,   1 running, 300 sleeping,   0 stopped,   0 zombie
Cpu(s): 10.7%us,  1.7%sy,  0.0%ni, 59.3%id, 27.5%wa,  0.0%hi,  0.7%si,  0.0%st
Mem:   8192360k total,  7867364k used,   324996k free,   171704k buffers
Swap:  1953784k total,   950944k used,  1002840k free,  1619948k cached

pstree输出如下

 oxygen@mail-1:~$ pstree
 init─┬─amavisd───10*[amavisd]
      ├─atd
      ├─clamd───{clamd}
      ├─cron
      ├─6*[getty]
      ├─ha_logd───ha_logd
      ├─heartbeat───3*[heartbeat]
      ├─hpasmxld───8*[{hpasmxld}]
      ├─httpd─┬─4*[httpd]
      │       └─sh───rotatelogs
      ├─httpd─┬─6*[httpd]
      │       └─2*[sh───rotatelogs]
      ├─irqbalance
      ├─master─┬─anvil
      │        ├─3*[cleanup]
      │        ├─2*[lmtp]
      │        ├─pickup
      │        ├─2*[proxymap]
      │        ├─qmgr
      │        ├─showq
      │        ├─3*[smtp]
      │        ├─6*[smtpd]
      │        ├─tlsmgr
      │        └─2*[trivial-rewrite]
      ├─miniserv.pl
      ├─mysqld_safe───mysqld───37*[{mysqld}]
      ├─named───10*[{named}]
      ├─nginx───nginx
      ├─nrpe
      ├─ntpd
      ├─nullmailer-send
      ├─openhpid───3*[{openhpid}]
      ├─perl───zmlogger───zmlogger
      ├─rsyslogd───3*[{rsyslogd}]
      ├─saslauthd───4*[saslauthd]
      ├─screen───2*[bash]
      ├─slapd───9*[{slapd}]
      ├─snmpd
      ├─sshd───sshd───sshd───bash───pstree
      ├─swatch───perl
      ├─udevd───2*[udevd]
      ├─upstart-udev-br
      ├─zmconfigdctl─┬─java───19*[{java}]
      │              └─sleep
      ├─zmmailboxdmgr───java───166*[{java}]
      ├─zmstat-allprocs
      ├─zmstat-convertd
      ├─zmstat-cpu
      ├─zmstat-df
      ├─zmstat-fd───zmstat-fd
      ├─2*[zmstat-io───iostat]
      ├─zmstat-mtaqueue
      ├─zmstat-mysql
      ├─zmstat-proc
      └─zmstat-vm───vmstat

不管怎样，这更像是一个内部溢出错误，ps而不是其他问题。我想不出 Java 还能用其他什么方式来消耗300万年79 天内的 CPU 时间！

答案1

我刚刚遇到了类似的问题，但几乎所有进程在重启后都会立即显示出极大的 CPU 时间。

您可以通过查看 /proc/$PID/stat 中的 utime 和 stime 列（我的内核中的第 14 和 15 列，检查 proc(5) 手册页以查看您的是否不同）来确保 ps 中没有溢出问题，例如：

cut -d' ' -f14,15 /proc/$PID/stat

这些是时钟滴答的数字，如果 ps 没有问题，它们将是非常大的值。

我正在运行 Scientific Linux 6.4（基于 RHEL 的发行版）并发现 kernel-2.6.32-358.6.2.el6.x86_64 存在问题。

我通过安装较新版本的内核（kernel-2.6.32-431.el6.x86_64）并重新启动来修复此问题。

我发现各种发行版都报告了类似的问题：

因此升级可能是解决问题的最佳方法。

答案2

安装系统状态（至少这是 Linux 软件包）并运行sar一周左右，然后分析其日志/统计信息。这样可以让你获得更长的时间视图，而不仅仅是你偶然注意到并登录时获得的快照。

日志中有什么奇怪的东西吗？不仅是系统本身，还有您正在运行的不同应用程序的日志？

相关内容