ps retornando valores excessivamente altos para% cpu e cputime

Question

Tivemos um alerta do Nagios em um de nossos servidores de que temos um processo descontrolado. Logar e executar top não mostra nada de ruim acontecendo, mas quando olho para a saída do ps, vejo algo estranho:

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 e cputime não parecem razoáveis. Alguma idéia de por que isso pode ser o caso?

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

EDITAR: Resposta aos comentários abaixo:

Sim, bom palpite, este é um servidor Zimbra.

As médias de carga são razoavelmente altas, esse servidor é ligado ao disco:

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 output como abaixo

 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

Por que vale a pena, parece mais um erro de estouro em ps do que qualquer outra coisa. Não consigo pensar em nenhuma outra maneira que o java consiga consumir 3 milhões de anos de cputime em 79 dias!

    

Answer 1

Acabei de ter um problema semelhante, mas com quase todos os processos mostrando tempos de CPU extremamente grandes imediatamente após a reinicialização.

Você pode ter certeza que não é problema com overflows em ps olhando para / proc / $ PID / stat para as colunas utime e stime (colunas 14 e 15 em meu kernel, verifique a página man proc (5) para veja se o seu é diferente), por exemplo:

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

Estes são números de marcações do relógio e, se não for um problema com o ps, eles serão valores extremamente grandes.

Estou executando o Scientific Linux 6.4 (uma distro baseada no RHEL) e vi o problema com o kernel-2.6.32-358.6.2.el6.x86_64.

Eu consertei instalando uma versão mais nova do kernel (kernel-2.6.32-431.el6.x86_64) e reinicializando.

Eu vejo que problemas semelhantes foram relatados para várias distribuições:

• link
• link

Portanto, a atualização é provavelmente a melhor maneira de corrigir o problema.

    

Answer 2

Instale sysstat (pelo menos esse é o pacote Linux) e execute sar por uma semana ou mais, em seguida, analise seus logs / estatísticas. Isso lhe dá uma visão de tempo mais longo, não apenas um instantâneo sempre que você perceber e efetuar login.

Algo estranho nos logs, não apenas para o sistema em si, mas para os diferentes aplicativos que você está executando?