Nagios在我们的一台服务器上发出警报，说我们有一个失控的进程。 login并运行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和cputime看起来不合理。 任何想法，为什么这可能是这样的？
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内的溢出错误比其他任何东西。 我想不出任何其他的方式将在79天内消耗300万年 CPU时间！
我刚刚也遇到了类似的问题，但几乎所有的进程在重新启动后立即显示非常大的CPU时间。
您可以通过查看utime和stime列的/ proc / $ PID / stat（我的内核中的第14和15列，请检查proc（5）手册页以查看您的是不同的），例如：
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）并重新启动来修复它。
我看到类似的问题已经报告了各种分布：
所以升级可能是解决问题的最好方法。
安装sysstat （至less是Linux软件包）并运行sar一个星期左右，然后分析它的日志/统计信息。 这给你一个更长时间的观点，而不仅仅是一个快照，当你注意到和login。
在日志中有什么奇怪的东西，不仅仅是系统本身，还有你正在运行的不同应用程序？