java süreçleri ile yüksek cpu / IO asılı ps aux

Java işlemi ve nrpe denetimleri ile ilgili bazı sorunlar yaşıyorum. 32 çekirdek sistemde bazen% 1000 işlemci kullanan bazı süreçlerimiz var. Sistem,

ps aux 

veya / proc / pid # like içinde herhangi bir şey yapmaya çalışın

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

Ps aux bir strace

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,

java süreci çalışıyor ve gayet iyi tamamlanacak ama sorun bizim izleme deli yapar düşünme süreçleri aşağı yapar çünkü bir ps aux tamamlanması için bekleyen zaman aşımları.

Gibi bir şey yapmayı denedim

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

şanssız

DÜZENLE

Sistem özellikleri

• 32 çekirdekli Intel (R) Xeon (R) CPU E5-2650 0 @ 2.00GHz
• 128g koç
• 12 4 TB 7200 sürücü
• CentOS 6.5
• Modelden emin değilim ama satıcı SuperMicro

Bu olduğunda yük 1 dakika boyunca 90-160ish arasındadır.

Garip kısmı başka / proc / pid # içine gidebilir ve gayet iyi çalışıyor. Ben ssh zaman sistem duyarlı. Biz yüksek yük uyarısı almak gibi ben sadece iyi ssh olabilir.

Başka bir düzenleme

Zamanlayıcı için son tarih kullanıyorum

[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

Mount benziyor

[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)

Tamam Ayarlanmış yüklemeyi denedim ve performansa ayarlanmış olmasını sağladım.

[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  ]

Genel olarak, bunun durmuş bir okuma nedeniyle olduğunu gördüm. Bu sizin straceçıktınız tarafından onaylanır . ps auxKomutu çalıştırırken / proc / xxxx / cmdline dosyasını okuma girişimi askıda kalıyor .

G / Ç'deki anlık artışlar sistemin kaynaklarını aç bırakıyor. Depolama altsistemiyle ilgili ise 90-160 yükü son derece kötü bir haberdir.

Depolama dizisi için, yerinde bir donanım RAID denetleyicisi olup olmadığını söyleyebilir misiniz? Sunucudaki birincil uygulama yazmaya taraflı mı? Bahsettiğiniz diskler (12 x 4 TB) düşük hızlı nearline SAS veya SATA diskleridir. Sürücü dizisinin önünde yazma önbellekleme biçimi yoksa , yazma işlemleri sistem yükünü yukarı doğru itebilir. Bunlar bir Supermicro arka panelindeki saf SATA sürücüler ise , diğer disk sorunlarının ( zaman aşımları, başarısız sürücü, arka panel vb. ) Olasılığını azaltmayın. Bu, tüm Hadoop düğümlerinde olur mu?

Kolay bir test, iotopbu sırada koşmaya çalışmaktır . Ayrıca, bu EL6.5 olduğundan, tuned-admayarlardan herhangi birini etkinleştirdiniz mi? Yazma engelleri etkin mi?

Sunucunun G / Ç asansörünü değiştirmediyseniz, ionicebir etkisi olabilir. CFQ dışında bir şeyle değiştirdiyseniz , ( bu sunucu muhtemelen son tarihte olmalıdır ), ioniceherhangi bir fark yaratmaz .

Düzenle:

Üretim ortamlarında gördüğüm bir diğer garip şey. Bunlar Java süreçleridir ve çok iş parçacıklı olduklarını varsayacağım. PID'lerde nasılsınız? Kernel.pid_max'ınsysctl değeri nedir ? Daha önce PID'leri tükettiğim ve sonuçta yüksek bir yük aldığım durumlar yaşadım.

Ayrıca, çekirdek sürümü 2.6.32-358.23.2.el6.x86_64'ten bahsediyorsunuz . Bu bir yıldan eski ve CentOS 6.4 sürümünün bir parçası, ancak sunucunuzun geri kalanı 6.5. Yum.conf dosyasında çekirdek güncellemelerini kara listeye aldınız mı? Muhtemelen bu sistem için 2.6.32-431.xx çekirdeğinde veya daha yenisinde olmalısınız. Eski çekirdeğinizde büyük bir sorun olabilir . Çekirdeği değiştiremiyorsanız, aşağıdakilerle devre dışı bırakmayı deneyin:

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

Sorun diskle ilgili bir sorun değil açıktır. Ve bu asılı askıda açıktır:

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

/ proc, çekirdek ve kullanıcı alanı arasındaki bir arabirimdir. Diske hiç dokunmuyor. Bir komutun argümanlarını okuyarak bir şey asılırsa, genellikle çekirdekle ilgili bir sorundur ve muhtemelen bir depolama sorunudur. @Kasperd açıklamasına bakın.

Yük sadece problemin bir yan etkisidir ve yüksek sayı tüm hikayeyi anlatmaz. Uygulamanın herhangi bir aksaklık olmadan davrandığı çok yüksek bir yüke sahip bir sunucunuz olabilir.

Neler olduğu hakkında daha fazla bilgi edinebilirsiniz cat /proc/$PID/stack. Okumanın $PIDdurduğu işlem kimliği nerede.

Senin durumunda bir çekirdek yükseltmesi ile başlardım.

Böylece tüm tweaks ve CentOS'un sağladığı en son 2.6 çekirdeğe yükseltme ile bile hala askıda kaldığını görüyoruz. Eskisi kadar değil ama hala onları görüyorum.

Çözüm, CentOS'un centosplus deposunda sağladığı 3.10.x serisi çekirdeğe geçmekti.

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

Bu, tüm işlem ağacı askıları ile ortadan kalkmıştır. Dediğim gibi, sistem yeni süreçlerin çalışmasının hızlı olmadığı herhangi bir çılgın yük altında değildi. Yani çoğu yerde bir 2.6 çekirdek sorunu olun.

Bu başka bir düzeltme.

Aşağıdaki baskın denetleyicisini çalıştırdığımız anlaşılıyor

Adaptec 71605

Etkilenen tüm makineler için en son sürüme ürün yazılımı güncellemeleri yapıyorum ve sorunu temizliyor gibi görünüyor.

CentOS 6'ya 3.10 yükleyen diğer rasgele sorunlar nedeniyle 3.10 çekirdek denemesinden eski sürüme geçmeliydik, ancak ürün yazılımı yükseltmesi sorunu çözüyor gibi görünüyor.