ps aux sospeso su alta CPU / IO con processi Java


13

Sto riscontrando alcuni problemi con il processo Java e i controlli nrpe. Abbiamo alcuni processi che a volte usano il 1000% di CPU su un sistema a 32 core. Il sistema è piuttosto reattivo fino a quando non si esegue un

ps aux 

o prova a fare qualcosa nel tipo / proc / pid #

[root@flume07.domain.com /proc/18679]# ls
hangs..

Una striscia di 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,

il processo java sta funzionando e si completerà perfettamente, ma il problema è che fa impazzire il nostro monitoraggio pensando che i processi sono inattivi perché è in timeout in attesa del completamento di un ps aux.

Ho provato a fare qualcosa del genere

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

senza fortuna

MODIFICARE

Specifiche di sistema

  • CPU Intel (R) Xeon (R) a 32 core E5-2650 0 a 2,00 GHz
  • 128gig di ram
  • 12 unità da 4 TB 7200
  • CentOS 6.5
  • Non sono sicuro del modello ma il venditore è SuperMicro

Il carico in questo caso è di circa 90-160ish per 1 minuto.

La parte strana è che posso andare in qualsiasi altro / proc / pid # e funziona benissimo. Il sistema è reattivo quando entro. Come quando veniamo avvisati di un carico elevato, posso andare bene.

Un'altra modifica

Ho usato la scadenza per lo scheduler

[root@dn07.domain.com ~]# 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

Il Monte sembra

[root@dn07.manage.com ~]# 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 ho provato a installare sintonizzato e averlo impostato per le prestazioni di throughput.

[root@dn07.domain.com ~]# 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  ]

Potete fornire informazioni sull'ambiente server? La distribuzione e la versione del sistema operativo, la piattaforma hardware sarebbero rilevanti.
ewwhite,

Anche il caricamento del sistema nel momento in cui ciò accade è importante.
ewwhite,

Ho apportato alcune modifiche con specifiche e qual è il carico
Mike

Che cosa significa l'uscita di mountassomigliare?
ewwhite,

Molto buona. Prendi in considerazione l'utilizzo del tuned-adm profile enterprise-storagecomando per gestire l'interruttore nobarrier e scadenza. Cosa dmesg|tailmostra l'output? Stai vedendo timeout I / O?
ewwhite,

Risposte:


8

In generale, l'ho visto accadere a causa di una lettura bloccata. Ciò è confermato dal tuo straceoutput. Il tentativo di leggere il file / proc / xxxx / cmdline si blocca durante l'esecuzione del ps auxcomando.

I picchi momentanei nell'I / O stanno facendo morire di fame le risorse del sistema. Un carico di 90-160 è una notizia estremamente negativa se si riferisce al sottosistema di archiviazione.

Per l'array di archiviazione, puoi dirci se è presente un controller RAID hardware? L'applicazione primaria sul server è distorta in scrittura? I dischi che menzioni (12 x 4 TB) sono dischi SAS o SATA nearline a velocità inferiore. Se non esiste alcuna forma di memorizzazione nella cache di scrittura davanti all'array di unità, le scritture sono in grado di aumentare il carico del sistema. Se si tratta di unità SATA pure su un backplane Supermicro, non scartare la possibilità di altri problemi del disco ( timeout, unità guasta, backplane, ecc. ) Succede su tutti i nodi Hadoop?

Un test semplice è provare a eseguire iotopmentre questo sta accadendo. Inoltre, poiché si tratta di EL6.5, hai abilitato alcune tuned-admimpostazioni ? Le barriere di scrittura sono abilitate?

Se non hai modificato l'ascensore I / O del server, ionicepotrebbe avere un impatto. Se lo hai cambiato in qualcosa di diverso da CFQ , ( questo server dovrebbe probabilmente essere in scadenza ), ionicenon farà alcuna differenza.

Modificare:

Un'altra cosa strana che ho visto negli ambienti di produzione. Questi sono processi Java e suppongo che siano fortemente multithread. Come va con i PID? Qual è il sysctlvalore di kernel.pid_max ? Ho avuto situazioni in cui ho esaurito i PID prima e ho avuto un carico elevato risultante.

Inoltre, menzioni la versione 2.6.32-358.23.2.el6.x6 del kernel del kernel . È più di un anno e fa parte della versione 6.4 di CentOS, ma il resto del server è 6.5. Hai inserito nella blacklist gli aggiornamenti del kernel in yum.conf? Probabilmente dovresti essere nel kernel 2.6.32-431.xx o più recente per quel sistema. Potrebbe esserci un problema di hugepages con il kernel più vecchio che hai . Se non riesci a cambiare il kernel, prova a disabilitarli con:

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


c'è una carta raid ma è appena usata per gestire 12 unità sul server. Fa parte di un cluster Hadoop, quindi scrive molto, ma anche questi blocchi vengono messi in atto quando il filo sta tirando molti dati per una mappa che riduce il lavoro.
Mike,

Sto chiedendo al datacenter di chiamarmi per vedere se sanno a cosa è impostato il controller raid per la cache di scrittura. Per quanto riguarda la scheda è un 3a0613065fa Adaptec \ 71605 \ SATA/SAS RAID ho verificato che sono anche unità SATA Western Digital WD RE WD4000FYYZ
Mike

1
@mike Se non riesci a modificare il kernel, prova: echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabledsu un computer interessato. Suppongo che questo sia abbastanza riproducibile da poter osservare un prima / un dopo con questa impostazione.
ewwhite,

4
sembra che l'ottimizzazione e la disabilitazione dell'hugepage abbiano aiutato a risolvere il problema!
Mike,

1
@Mike Eccellente. Un aggiornamento del kernel può anche fornire un po 'di sollievo. Ma se sei bloccato con il kernel in esecuzione, sono contento che questa correzione funzioni.
ewwhite,

3

Il problema è chiaro non è un problema relativo al disco. E questo è chiaro dalla striscia impiccata:

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

/ proc è un'interfaccia tra kernel e spazio utente. Non tocca affatto il disco. Se qualcosa viene appeso leggendo gli argomenti di un comando, di solito si tratta di un problema relativo al kernel e, probabilmente, di archiviazione. Vedi il commento di @kasperd.

Il carico è solo un effetto collaterale del problema e il numero elevato non racconta la storia completa. Potresti avere un server con un carico molto elevato su cui l'applicazione si comporta senza alcun problema tecnico.

Puoi ottenere maggiori informazioni su ciò che sta accadendo cat /proc/$PID/stack. Dov'è $PIDl'ID processo in cui la lettura si blocca.

Nel tuo caso, vorrei iniziare con un aggiornamento del kernel.


2
Ti stai sbagliando. Ciò che viene restituito dalla lettura /proc/%d/cmdlineè la parte dello spazio degli indirizzi del processo in cui il kernel ha memorizzato la riga di comando durante la execvechiamata. Come qualsiasi altra parte dello spazio utente, può essere sostituito. Pertanto, per accedervi potrebbe essere necessario attendere che la pagina venga nuovamente scambiata.
Kasperd,

Questa è un'ottima argomentazione. Grazie per esserti alzato. Tuttavia, penso che le possibilità che inizi lo strace quando lo swap non risponde sono basse, ma non impossibili. Aggiornerò la mia risposta.
Mircea Vutcovici,

2

Quindi, nonostante tutte le modifiche e un aggiornamento all'ultimo kernel 2.6 fornito da CentOS, stavamo ancora vedendo i blocchi. Non tanto quanto prima ma ancora li vedo.

La correzione era l'aggiornamento al kernel della serie 3.10.x fornito da CentOS nel repository centosplus qui

http://mirror.centos.org/centos/6/xen4/x86_64/Packages/

Questo ha eliminato tutti i blocchi dell'albero dei processi. Come ho detto, il sistema non era soggetto a carichi folli in cui l'esecuzione di nuovi processi non era scattante. Quindi la maggior parte è un problema del kernel 2.6 da qualche parte.


0

Questa è un'altra soluzione.

Sembra che stiamo eseguendo il seguente controller raid

Adaptec 71605

Ho effettuato aggiornamenti del firmware di tutte le macchine interessate all'ultima versione e sembra che stia risolvendo il problema.

Abbiamo dovuto eseguire il downgrade dall'esperimento del kernel 3.10 a causa di altri problemi casuali durante l'installazione di 3.10 su CentOS 6, ma l'aggiornamento del firmware sembra risolvere il problema.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.