Estou tendo alguns problemas com o processo java e verificações nrpe. Temos alguns processos que às vezes usam 1000% da CPU em um sistema de 32 núcleos. O sistema é bastante responsivo até que você faça um
ps aux
ou tente fazer qualquer coisa no /proc/pid# como
[[email protected] /proc/18679]# ls
hangs..
Um strace 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 muito bem, mas o problema é que isso faz nosso monitoramento enlouquecer pensando que os processos estão inativos porque o tempo limite de espera de um ps aux é concluído.
Eu tentei fazer algo como
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(R) Xeon(R) de 32 núcleos E5-2650 0 a 2,00 GHz
- 128gig de carneiro
- 12 unidades de 4 TB 7200
- CentOS 6.5
- Não tenho certeza do modelo, mas o fornecedor é SuperMicro
A carga quando isso acontece é de cerca de 90-160ish por 1 minuto.
A parte estranha é que posso entrar em qualquer outro /proc/pid# e funciona muito bem. O sistema é responsivo quando eu ssh in. Como quando somos alertados sobre carga alta, posso fazer ssh perfeitamente.
outra edição
Eu tenho usado deadline para 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
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 Tuned e configurá-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 ]
Em geral, já vi isso acontecer por causa de uma leitura paralisada. Isso é confirmado pela sua
strace
saída. A tentativa de ler o arquivo /proc/xxxx/cmdline trava enquanto você está executando ops aux
comando.Os picos momentâneos de E/S estão esgotando os recursos do sistema. Uma carga de 90-160 é uma notícia extremamente ruim se estiver relacionada ao subsistema de armazenamento.
Para a matriz de armazenamento, você pode nos dizer se há um controlador RAID de hardware instalado? O aplicativo principal no servidor está com tendência de gravação? Os discos que você mencionou (12 x 4 TB) são discos SAS ou SATA nearline de baixa velocidade. Se não houver nenhuma forma de cache de gravação na frente da matriz da unidade, as gravações são capazes de aumentar a carga do sistema. Se forem unidades SATA puras em um backplane Supermicro, não descarte a possibilidade de outros problemas de disco ( tempo limite, unidade com falha, 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 é EL6.5, você tem alguma dastuned-adm
configurações ativadas? As barreiras de gravação estão ativadas?Se você não alterou o elevador de E/S do servidor,
ionice
pode haver um impacto. Se você alterou para algo diferente de CFQ , ( este servidor provavelmente deve estar dentro do prazo ),ionice
não fará nenhuma diferença.Editar:
Outra coisa estranha que vi em ambientes de produção. Esses são processos Java e presumo que sejam altamente multiencadeados. Como você está indo em PIDs? Qual é o
sysctl
valor para kernel.pid_max ? Já tive situações em que esgotei os PIDs antes e tive uma carga alta resultante.Além disso, você menciona a versão do kernel 2.6.32-358.23.2.el6.x86_64 . Isso tem mais de um ano e faz parte da versão CentOS 6.4, mas o restante do seu servidor é 6.5. Você colocou na lista negra as atualizações do kernel no yum.conf? Você provavelmente deve estar no kernel 2.6.32-431.xx ou mais recente para esse sistema. Pode haver um problema de páginas enormes com o kernel mais antigo que você possui . Se você não pode alterar o kernel, tente desativá-los com:
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
.O problema é claro, não é um problema relacionado ao disco. E isso fica claro no strace enforcado:
/proc é uma interface entre o kernel e o espaço do usuário. Ele não toca o disco em tudo. Se algo for interrompido ao ler os argumentos de um comando, geralmente é um problema relacionado ao kernel e, provavelmente, um problema de armazenamento. Veja o comentário de @kasperd.
A carga é apenas um efeito colateral do problema e o número alto não conta a história completa. Você pode ter um servidor com carga muito alta no qual o aplicativo se comporta sem nenhuma falha.
Você pode obter mais informações sobre o que está acontecendo com
cat /proc/$PID/stack
. Onde$PID
está o ID do processo onde a leitura para.No seu caso, eu começaria com uma atualização do kernel.
Portanto, mesmo com todos os ajustes e uma atualização para o kernel 2.6 mais recente fornecido pelo CentOS, ainda estávamos 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
http://mirror.centos.org/centos/6/xen4/x86_64/Packages/
Isso eliminou todas as interrupções da árvore de processo. Como eu disse, o sistema não estava sob nenhuma carga louca, onde a execução de novos processos não era rápida. Portanto, a maioria é um problema do kernel 2.6 em algum lugar.
Esta é outra correção.
Parece que estamos executando o seguinte controlador RAID
Tenho feito atualizações de firmware para todas as máquinas afetadas para a versão mais recente e parece estar resolvendo o problema.
Tivemos que fazer o downgrade do experimento do kernel 3.10 devido a outros problemas aleatórios na instalação do 3.10 no CentOS 6, mas a atualização do firmware parece corrigir o problema.