ps aux appeso ad alta CPU / IO con processi java

Sto avendo alcune problematiche con i processi java e i controlli nrpe. Abbiamo alcuni processi che talvolta usano la CPU di 1000% su un sistema a 32 core. Il sistema è abbastanza reattivo fino a quando non si fa una

ps aux 

o cercare di fare qualcosa nel / proc / pid # come

  • Come get OpenVPN Client (Mikrotik RouterOS) <-> Impostazione server OpenVPN (Debian / Linux) per funzionare
  • Qual è l'unità di "mem" e "memory" in / proc / net / sockstat
  • Che cosa è una buona soluzione per molteplici installazioni di software?
  • Eliminare each pacchetto con una determinata string nel suo nome
  • Centos 6.3 allocazione di spazio su disco
  • Come estendere LVM PV all'inizio del disco?
  •  [root@flume07.domain.com /proc/18679]# ls hangs.. 

    Un strace 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 process java sta funzionando e sarà completo bene, ma il problema è che rende il nostro monitoraggio vanno i processi di pensiero sono in discesa perché i timeout in attesa di un ps aux completare.

    Ho provato a fare qualcosa di simile

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

    senza fortuna

    EDIT

    Specifiche di sistema

    • 32 core Intel (R) Xeon (R) CPU E5-2650 0 a 2.00GHz
    • 128gig di ram
    • 12 unità 4Tb 7200
    • CentOS 6.5
    • Non sono sicuro del model ma il venditore è SuperMicro

    Il carico quando questo accade è di circa 90-160ish per 1 minuto.

    La parte strana è che posso andare in qualsiasi altro / proc / pid # e funziona bene. Il sistema è sensibile quando i ssh in. Come quando ci viene avvisato di un carico elevato posso ssh proprio in bene.

    Un'altra modifica

    Ho utilizzato la scadenza per il pianificatore

     [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 montone assomiglia

     [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 ad installare accordato e impostarlo su performance 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 ] 

    4 Solutions collect form web for “ps aux appeso ad alta CPU / IO con processi java”

    In generale, ho visto questo accadere a causa di una lettura in stallo. Questo è confermato dalla tua output strace . Il tentativo di leggere il file / proc / xxxx / cmdline si blocca durante l'esecuzione di un command ps aux .

    I picchi momentanei in I / O stanno affamando le risorse del sistema. Un carico di 90-160 è notizie negative se si tratta di sottosisthemes di storage.

    Per l'arrays di archiviazione, puoi dirci se c'è un controller RAID hardware? L'applicazione primaria sul server è biased? I dischi citati (12 x 4TB) sono i dischi SAS o SATA vicino a velocità minima. Se non c'è alcuna forma di scrittura nella cache di fronte all'arrays di unità, le scritture sono in grado di spingere il sistema verso l'alto. Se questi sono unità SATA a puro su un backplane Supermicro, non scontate la possibilità di altri problemi di disco ( timeout, guasto, backplane, ecc. ) . Ciò accade su tutti i nodes Hadoop?

    Un test facile è quello di provare a eseguire iotop mentre questo sta accadendo. Inoltre, dato che questo è EL6.5, hai abilitato qualsiasi impostazione tuned-adm ? Sono abilitate le barriere di scrittura?

    Se non hai modificato l'ascensore I / O del server, l' ionice potrebbe avere un impatto. Se l'hai cambiato su qualsiasi cosa diversa da CFQ ( questo server probabilmente dovrebbe essere in scadenza ), ionice non farà alcuna differenza.

    Edit:

    Un'altra cosa strana che ho visto negli ambienti di produzione. Questi sono i processi Java e suppongo che siano molto multithreaded. Come stai facendo in PID? Qual è il valore sysctl per kernel.pid_max ? Ho avuto situazioni in cui ho esaurito i PID prima e ho avuto un carico elevato.

    Inoltre, si menziona la versione del kernel 2.6.32-358.23.2.el6.x86_64 . Questo è più di un anno e parte della release CentOS 6.4, ma il resto del tuo server è 6,5. Hai aggiornato i nodes di kernel in yum.conf? Si dovrebbe probabilmente essere sul kernel 2.6.32-431.xx o più nuovo per quel sistema. Ci potrebbe essere un problema di enormi pagine con il kernel più vecchio che hai . Se non è ansible modificare il kernel, provare a distriggersrli con:

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

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

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

    / proc è un'interface tra kernel e userspace. Non tocca il disco affatto. Se qualcosa viene impiccato leggendo gli argomenti di un command, di solito è un problema correlato al kernel, e improbabile che sia uno storage. Vedere il commento @kasperd.

    Il carico è solo un effetto collaterale del problema e il numero elevato non indica la storia completa. Si potrebbe avere un server con un carico molto elevato su cui l'applicazione si comport senza alcun problema.

    È ansible get ulteriori informazioni su ciò che sta accadendo con cat /proc/$PID/stack . Dove $PID è l'ID di process in cui il banco di lettura.

    Nel tuo caso vorrei iniziare con un aggiornamento del kernel.

    Così anche con tutte le modifiche e un aggiornamento all'ultimo kernel 2.6 che CentOS fornisce noi stiamo ancora vedendo le appende. Non tanto quanto prima, ma ancora vederli.

    La correzione era di aggiornare al kernel della serie 3.10.x che CentOS fornisce nel loro repo centosplus qui

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

    Questo ha eliminato tutti i blocchi dell'tree di process. Come ho detto, il sistema non era sotto nessun carico pazzo where l'esecuzione di nuovi processi non era snappy. Quindi la maggior parte è un problema di kernel 2.6 da qualche parte.

    Questa è un'altra soluzione.

    Sembra che stiamo eseguendo il seguente controller di raid

     Adaptec 71605 

    Sto facendo aggiornamenti del firmware a tutte le macchine interessate alla versione più recente e sembra che sta risanando il problema.

    Abbiamo dovuto ridimensionare dall'esperimento del kernel 3.10 a causa di altri problemi casuali installando 3.10 su CentOS 6 ma l'aggiornamento del firmware sembra risolvere il problema.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.