ps aux pendurado em alta cpu / IO com processos java

Question

Estou tendo alguns problemas com o processo java e com as verificações nrpe. Temos alguns processos que às vezes usam cpu de 1000% em um sistema de 32 núcleos. O sistema é bem responsivo até que você faça um

ps aux 

ou tente fazer qualquer coisa no / proc / pid # like

[[email protected] /proc/18679]# ls
hangs..

Uma faixa de ps aux

stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0
stat("/dev/pts1", 0x7fffb8526f00)       = -1 ENOENT (No such file or directory)
stat("/dev/pts", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
readlink("/proc/15693/fd/2", "/dev/pts/1", 127) = 10
stat("/dev/pts/1", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
write(1, "root     15693 15692  0 06:25 pt"..., 55root     15693 15692  0 06:25 pts/1    00:00:00 ps -Af
) = 55
stat("/proc/18679", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc/18679/stat", O_RDONLY)      = 5
read(5, "18679 (java) S 1 18662 3738 3481"..., 1023) = 264
close(5)                                = 0
open("/proc/18679/status", O_RDONLY)    = 5
read(5, "Name:\tjava\nState:\tS (sleeping)\nT"..., 1023) = 889
close(5)                                = 0
open("/proc/18679/cmdline", O_RDONLY)   = 5
read(5,

o processo java está funcionando e será concluído, mas o problema é que o monitoramento fica ruim porque os processos estão em espera porque os tempos limite estão aguardando a conclusão de um ps aux.

Eu tentei fazer algo parecido com

 nice -19 ionice -c1 /usr/lib64/nagios/plugins/check_procs -w 1:1 -c 1:1 -a 'diamond' -u root -t 30

sem sorte

EDITAR

Especificações do sistema

• CPU Intel (X) Xeon (R) de 32 núcleos E5-2650 0 @ 2.00GHz
• 128gig de ram
• 12 4 TB de 7200 drives
• CentOS 6.5
• Não tenho certeza do modelo, mas o fornecedor é o SuperMicro

A carga quando isso acontece é em torno de 90-160ish por 1 minuto.

A parte ímpar é que eu posso entrar em qualquer outro / proc / pid # e funciona muito bem. O sistema é sensível quando eu ssh dentro Como quando somos alertados de carga alta eu posso ssh bem em muito bem.

Outra edição

Estou usando o prazo final para o agendador

[[email protected] ~]# for i in {a..m}; do cat /sys/block/sd${i}/queue/scheduler; done
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq

A montagem parece

[[email protected] ~]# mount
/dev/sda3 on / type ext4 (rw,noatime,barrier=0)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext2 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/dev/sdb1 on /disk1 type xfs (rw,nobarrier)
/dev/sdc1 on /disk2 type xfs (rw,nobarrier)
/dev/sdd1 on /disk3 type xfs (rw,nobarrier)
/dev/sde1 on /disk4 type xfs (rw,nobarrier)
/dev/sdf1 on /disk5 type xfs (rw,nobarrier)
/dev/sdg1 on /disk6 type xfs (rw,nobarrier)
/dev/sdh1 on /disk7 type xfs (rw,nobarrier)
/dev/sdi1 on /disk8 type xfs (rw,nobarrier)
/dev/sdj1 on /disk9 type xfs (rw,nobarrier)
/dev/sdk1 on /disk10 type xfs (rw,nobarrier)
/dev/sdl1 on /disk11 type xfs (rw,nobarrier)
/dev/sdm1 on /disk12 type xfs (rw,nobarrier)

Ok, tentei instalar o ajuste e defini-lo para o desempenho da taxa de transferência.

[[email protected] ~]# tuned-adm profile throughput-performance
Switching to profile 'throughput-performance'
Applying deadline elevator: sda sdb sdc sdd sde sdf sdg sdh[  OK  ] sdk sdl sdm
Applying ktune sysctl settings:
/etc/ktune.d/tunedadm.conf:                                [  OK  ]
Calling '/etc/ktune.d/tunedadm.sh start':                  [  OK  ]
Applying sysctl settings from /etc/sysctl.d/99-chef-attributes.conf
Applying sysctl settings from /etc/sysctl.conf
Starting tuned:                                            [  OK  ]

    

Answer 1

Em geral, eu vi isso acontecer por causa de uma leitura interrompida. Isso é confirmado pela sua saída strace . A tentativa de ler o arquivo / proc / xxxx / cmdline trava enquanto você está executando o comando ps aux .

Os picos momentâneos em E / S estão privando os recursos do sistema. Uma carga de 90-160 é uma péssima notícia se for relacionada ao subsistema de armazenamento.

Para o storage array, você pode nos informar se existe um controlador RAID de hardware? O aplicativo principal no servidor é influenciado por gravação? Os discos que você menciona (12 x 4 TB) são discos SAS ou SATA nearline de baixa velocidade. Se não houver nenhuma forma de gravação em cache na frente da matriz da unidade, as gravações são capazes de elevar o carregamento do sistema. Se forem unidades SATA puras em um backplane Supermicro, não desconsidere o possibilidade de outros problemas de disco ( timeouts, falha na unidade, backplane, etc. ) isso acontece em todos os nós do Hadoop?

Um teste fácil é tentar executar iotop enquanto isso está acontecendo. Além disso, como este é o EL6.5, você tem alguma das tuned-adm configurações ativado? As barreiras de escrita estão habilitadas?

Se você não alterou o elevador de E / S do servidor, ionice pode ter um impacto. Se você mudou para algo diferente de CFQ , ( este servidor provavelmente deve estar em deadline ), ionice não fará qualquer diferença.

Editar:

Uma outra coisa estranha que eu vi em ambientes de produção. Esses são processos Java e suponho que sejam altamente multithread. Como você está fazendo em PIDs? Qual é o valor de sysctl para kernel.pid_max ? Eu tive situações em que eu já exaurei PIDs e tive uma alta carga resultante.

Além disso, você menciona a versão do kernel 2.6.32-358.23.2.el6.x86_64 . Tem mais de um ano e faz parte da versão do CentOS 6.4, mas o resto do seu servidor é 6.5. Você bloqueou as atualizações do kernel no yum.conf? Você provavelmente deveria estar no kernel 2.6.32-431.x.x ou mais recente para esse sistema. Poderia haver um problema nas páginas iniciais com o kernel antigo . Se você não pode mudar o kernel, tente desabilitá-los com:

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled .

    

Answer 2

O problema é claro, não um problema relacionado ao disco. E isso fica claro a partir do strace enforcado:

open("/proc/18679/cmdline", O_RDONLY)   = 5
read(5,

/ proc é uma interface entre o kernel e o userspace. Não toca no disco de jeito nenhum. Se algo for enforcado lendo os argumentos de um comando, geralmente é um problema relacionado ao kernel, e é improvável que ocorra um armazenamento. Veja o comentário do @kasperd.

A carga é apenas um efeito colateral do problema e o número alto não conta a história completa. Você poderia ter um servidor com carga muito alta na qual o aplicativo se comporta sem qualquer falha.

Você pode obter mais informações sobre o que está acontecendo com cat /proc/$PID/stack . Onde $PID é o ID do processo em que a leitura fica paralisada.

No seu caso eu começaria com uma atualização do kernel.

    

Answer 3

Assim, mesmo com todos os ajustes e uma atualização para o kernel 2.6 mais recente que o CentOS fornece, ainda estamos vendo os travamentos. Não tanto quanto antes, mas ainda os vendo.

A correção foi atualizar para o kernel da série 3.10.x que o CentOS fornece em seu repositório centosplus aqui

link

Isso eliminou todos os bloqueios de árvore do processo. Como eu disse, o sistema não estava sob nenhuma carga maluca onde executar novos processos não era ágil. Então, a maioria é um problema do kernel 2.6 em algum lugar.

    

Answer 4

Esta é outra correção.

Parece que estamos executando o seguinte controlador de ataque

Adaptec 71605

Eu tenho feito atualizações de firmware em todas as máquinas afetadas para a versão mais recente e parece estar resolvendo o problema.

Tivemos que rebaixar o experimento do kernel 3.10 devido a outros problemas aleatórios que instalam o 3.10 no CentOS 6, mas a atualização do firmware parece corrigir o problema.