ps aux tergantung pada cpu / IO tinggi dengan proses java

Saya mengalami beberapa masalah dengan proses java dan cek nrpe. Kami memiliki beberapa proses yang terkadang menggunakan 1000% cpu pada sistem 32 core. Sistem ini cukup responsif sampai Anda melakukan

ps aux 

atau coba lakukan apa saja di / proc / pid # like

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

Sejumlah 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,

proses java bekerja dan akan menyelesaikan dengan baik tetapi masalah ini membuat pemantauan go go kami berpikir proses turun karena timeout menunggu ps aux selesai.

Saya sudah mencoba melakukan sesuatu seperti

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

tanpa keberuntungan

EDIT

Spesifikasi sistem

• 32 core Intel (R) Xeon (R) CPU E5-2650 0 @ 2.00GHz
• 128 ram
• 12 4Tb 7200 drive
• CentOS 6.5
• Saya tidak yakin model tetapi vendornya adalah SuperMicro

Beban ketika ini terjadi sekitar 90-160ish selama 1 menit.

Bagian yang aneh adalah saya bisa masuk ke yang lain / proc / pid # dan berfungsi dengan baik. Sistem ini responsif ketika saya ssh in. Seperti ketika kita mendapat peringatan tentang beban tinggi saya dapat ssh dengan baik.

Sunting lagi

Saya telah menggunakan tenggat waktu untuk penjadwal

[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

Gunung terlihat seperti

[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 saya mencoba untuk menginstal disetel dan mengaturnya untuk kinerja 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  ]

Secara umum, saya telah melihat ini terjadi karena membaca-buntu. Ini dikonfirmasi oleh straceoutput Anda . Upaya membaca / proc / xxxx / cmdline hang ketika Anda menjalankan ps auxperintah.

Lonjakan sesaat di I / O membuat sumber daya sistem kelaparan. Beban 90-160 adalah berita yang sangat buruk jika terkait dengan subsistem penyimpanan.

Untuk larik penyimpanan, dapatkah Anda memberi tahu kami jika ada pengontrol RAID perangkat keras? Apakah aplikasi utama pada server bias menulis? Disk yang Anda sebutkan (12 x 4TB) adalah disk SAS atau SATA nearline berkecepatan lebih rendah. Jika tidak ada bentuk cache tulis di depan array drive, write mampu mendorong sistem load naik. Jika ini adalah drive SATA murni pada Supermicro backplane, jangan mengabaikan kemungkinan masalah disk lain ( timeout, gagal drive, backplane, dll. ) Apakah ini terjadi pada semua node Hadoop?

Tes yang mudah adalah mencoba menjalankan iotopsementara ini terjadi. Juga, karena ini adalah EL6.5, apakah Anda memiliki tuned-admpengaturan yang diaktifkan? Apakah hambatan tulis diaktifkan?

Jika Anda belum mengubah lift I / O server, ionicemungkin berdampak. Jika Anda telah mengubahnya ke selain CFQ , ( server ini mungkin harus pada batas waktu ), ionicetidak akan ada bedanya.

Edit:

Satu hal aneh lain yang pernah saya lihat di lingkungan produksi. Ini adalah proses Java, dan saya akan menganggap mereka sangat multithreaded. Bagaimana kabar Anda tentang PID? Apa sysctlnilai untuk kernel.pid_max ? Saya pernah mengalami situasi di mana saya sudah kehabisan PID sebelumnya dan menghasilkan beban yang tinggi.

Juga, Anda menyebutkan versi kernel 2.6.32-358.23.2.el6.x86_64 . Itu lebih dari setahun dan bagian dari rilis CentOS 6.4, tetapi sisa server Anda adalah 6.5. Apakah Anda daftar hitam pembaruan kernel di yum.conf? Anda mungkin berada di kernel 2.6.32-431.xx atau yang lebih baru untuk sistem itu. Mungkin ada masalah hugepages dengan kernel lama yang Anda miliki . Jika Anda tidak dapat mengubah kernel, coba nonaktifkan dengan:

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

Masalahnya jelas bukan masalah terkait disk. Dan ini jelas dari strace yang digantung:

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

/ proc adalah antarmuka antara kernel dan userspace. Tidak menyentuh disk sama sekali. Jika sesuatu digantung membaca argumen dari suatu perintah biasanya itu adalah masalah yang berhubungan dengan kernel, dan tidak mungkin yang penyimpanan. Lihat komentar @kasperd.

Beban hanyalah efek samping dari masalah dan jumlah yang tinggi tidak menceritakan kisah lengkapnya. Anda bisa memiliki server dengan beban sangat tinggi tempat aplikasi berperilaku tanpa kesalahan.

Anda dapat memperoleh informasi lebih lanjut tentang apa yang terjadi cat /proc/$PID/stack. Di $PIDmana ID proses tempat bacaan dibaca.

Dalam kasus Anda, saya akan mulai dengan peningkatan kernel.

Begitu pun dengan semua tweak dan peningkatan ke kernel 2.6 terbaru yang disediakan CentOS, kami masih melihat hang. Tidak sebanyak sebelumnya tetapi masih melihat mereka.

Cara mengatasinya adalah meng-upgrade ke kernel seri 3.10.x yang disediakan CentOS di repo centosplus mereka di sini

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

Ini telah menghilangkan semua pohon proses hang. Seperti saya katakan sistem tidak di bawah beban gila di mana menjalankan proses baru tidak cepat. Jadi sebagian besar masalah kernel 2.6 di suatu tempat.

Ini adalah perbaikan lain.

Sepertinya kita menjalankan pengontrol serangan berikut

Adaptec 71605

Saya telah melakukan pembaruan firmware untuk semua mesin yang terpengaruh ke versi terbaru dan tampaknya akan menyelesaikan masalah.

Kami harus menurunkan versi dari percobaan kernel 3,10 karena masalah acak lainnya menginstal 3,10 pada CentOS 6 tetapi upgrade firmware tampaknya untuk memperbaiki masalah.