ps aux tergantung pada cpu / IO tinggi dengan proses java


13

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  ]

Bisakah Anda memberikan informasi tentang lingkungan server? Distribusi dan versi OS, platform perangkat keras akan relevan.
ewwhite

Sistem Anda memuat pada titik ketika ini terjadi juga penting.
ewwhite

Saya melakukan beberapa pengeditan dengan spesifikasi dan bebannya
Mike

Seperti apa bentuk outputnya mount?
ewwhite

Baik sekali. Pertimbangkan untuk menggunakan tuned-adm profile enterprise-storageperintah untuk menangani saklar nobarrier dan tenggat waktu. Apa yang dmesg|tailditunjukkan oleh output? Apakah Anda melihat batas waktu I / O?
ewwhite

Jawaban:


8

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.


ada kartu raid tetapi hanya digunakan untuk menangani 12 drive di server. Ini bagian dari cluster Hadoop sehingga tidak banyak menulis tetapi juga penguncian ini terjadi ketika benang menarik banyak data untuk peta mengurangi pekerjaan.
Mike

Saya meminta datacenter menelepon saya untuk melihat apakah mereka tahu apa yang diatur untuk raid controller cache. Adapun kartu yang 3a0613065fa Adaptec \ 71605 \ SATA/SAS RAID saya memverifikasi mereka drive SATA juga Western Digital WD RE WD4000FYYZ
Mike

1
@mike Jika Anda tidak dapat melakukan perubahan kernel, coba: echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabledpada mesin yang terpengaruh. Saya berasumsi ini cukup dapat direproduksi sehingga Anda dapat mengamati sebelum / sesudah dengan pengaturan ini.
ewwhite

4
sepertinya disetel dan menonaktifkan hugepage membantu memperbaiki masalah!
Mike

1
@ Mike Excellent. Pembaruan kernel juga dapat membantu. Tetapi jika Anda terjebak dengan kernel yang sedang berjalan, saya senang perbaikan ini berhasil.
ewwhite

3

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.


2
Anda salah. Apa yang dikembalikan dengan membaca /proc/%d/cmdlineadalah bagian dari ruang alamat proses di mana kernel menyimpan baris perintah selama execvepanggilan. Seperti bagian lain dari ruang pengguna, ini dapat ditukar. Jadi mengaksesnya mungkin memang harus menunggu halaman untuk ditukar lagi.
kasperd

Ini argumen yang sangat bagus. Terima kasih sudah bangun. Namun saya berpikir bahwa peluang untuk memulai ketika swap Anda tidak dijawab rendah, tetapi bukan tidak mungkin. Saya akan memperbarui jawaban saya.
Mircea Vutcovici

2

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.


0

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.