导致负载的进程从“顶部”消失 ps -o pcpu 显示虚假数字

导致负载的进程从“顶部”消失 ps -o pcpu 显示虚假数字

我管理大量服务器,只有 Ubuntu 10.04 LTS 才会出现此问题:我运行的服务器负载正常(例如 8 核服务器上的平均负载为 3.0)。“top”命令显示占用一定百分比 CPU 的进程,这些进程导致此平均负载:例如

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
11008 mysql     20   0 25.9g  22g 5496 S   67 76.0 643539:38 mysqld  

ps -o pcpu,pid -p11008
%CPU   PID
53.1 11008

,一切都一致。

突然间,导致平均负载的进程从“top”中消失,但该进程继续正常运行(尽管性能略有下降),系统平均负载略有升高。ps -o pcpu 的输出变得虚假:

# ps -o pcpu,pid -p11008
%CPU      PID
317910278 1587

这种情况至少发生在 5 个不同的服务器上(不同的全新 IBM System X 硬件),每个服务器运行不同的软件:一个 httpd 2.2、一个 mysqld 5.1 和一个 Twisted Python TCP 服务器。每次内核都在 2.6.32-32-server 和 2.6.32-40-server 之间。我将一些机器更新到 2.6.32-41-server,这些机器上还没有发生这种情况,但这种错误很少见(大约每 60 天一次)。

这是来自一台受影响的机器:

top - 10:39:06 up 73 days, 17:57,  3 users,  load average: 6.62, 5.60, 5.34
Tasks: 207 total,   2 running, 205 sleeping,   0 stopped,   0 zombie
Cpu(s): 11.4%us, 18.0%sy,  0.0%ni, 66.3%id,  4.3%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  74341464k total, 71985004k used,  2356460k free,   236456k buffers
Swap:  3906552k total,      328k used,  3906224k free, 24838212k cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                
805 root      20   0     0    0    0 S    3  0.0   1493:09 fct0-worker                                                            
982 root      20   0     0    0    0 S    1  0.0 111:35.05 fioa-data-groom                                                        
914 root      20   0     0    0    0 S    0  0.0 884:42.71 fct1-worker                                                            
1068 root      20   0 19364 1496 1060 R    0  0.0   0:00.02 top             

顶部没有显示任何导致高负载的情况,但我有两个高负载的 mysqld 实例,它们突然显示疯狂%中央处理器

#ps -o pcpu,pid,cmd -p1587
%CPU   PID CMD
317713124 1587 /nail/encap/mysql-5.1.60/libexec/mysqld

#ps -o pcpu,pid,cmd -p1624
%CPU   PID CMD
2802  1624 /nail/encap/mysql-5.1.60/libexec/mysqld

以下是

 # cat /proc/1587/stat
 1587 (mysqld) S 1212 1088 1088 0 -1 4202752 14307313 0 162 0 85773299069     4611685932654088833 0 0 20 0 52 0 3549 27255418880 5483524 18446744073709551615 4194304 11111617 140733749236976 140733749235984 8858659 0 552967 4102 26345 18446744073709551615 0 0 17 5 0 0 0 0 0

第 14 和第 15 个数字

man proc 

应该是

utime %lu   Amount of time that this process has been scheduled in user mode, measured in clock ticks  (divide  by
                      sysconf(_SC_CLK_TCK).   This  includes  guest  time, guest_time (time spent running a virtual CPU, see
                      below), so that applications that are not aware of the guest time field do not  lose  that  time  from
                      their calculations.

stime %lu   Amount of time that this process has been scheduled in kernel mode, measured in clock ticks (divide by
                      sysconf(_SC_CLK_TCK).

在正常的服务器上,每次我检查 /proc/PID/stat 时,这些数字都在增加。在有缺陷的服务器上,这些数字停留在一个非常高的值上,如 4611685932654088833,并且没有变化。

有谁遇到过这个错误吗?

答案1

我猜这可能是procps软件包中的错误,而不是内核中的错误。没有看到您描述的错误,但多年来各个发行版中都存在类似的错误,是的。

如果这是关于 procps 的,那么是否有适用于 Ubuntu 10.04 LTS 的错误修复?不知道,已经很久很久没有使用它了,而且最后一次使用也是在很远很远的星系中……

相关内容