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
[[email protected] /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
[[email protected] ~]# 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
[[email protected] ~]# 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.
[[email protected] ~]# 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 ]
mount
?tuned-adm profile enterprise-storage
perintah untuk menangani saklar nobarrier dan tenggat waktu. Apa yangdmesg|tail
ditunjukkan oleh output? Apakah Anda melihat batas waktu I / O?Jawaban:
Secara umum, saya telah melihat ini terjadi karena membaca-buntu. Ini dikonfirmasi oleh
strace
output Anda . Upaya membaca / proc / xxxx / cmdline hang ketika Anda menjalankanps aux
perintah.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
iotop
sementara ini terjadi. Juga, karena ini adalah EL6.5, apakah Anda memilikituned-adm
pengaturan yang diaktifkan? Apakah hambatan tulis diaktifkan?Jika Anda belum mengubah lift I / O server,
ionice
mungkin berdampak. Jika Anda telah mengubahnya ke selain CFQ , ( server ini mungkin harus pada batas waktu ),ionice
tidak 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
sysctl
nilai 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
.sumber
3a0613065fa Adaptec \ 71605 \ SATA/SAS RAID
saya memverifikasi mereka drive SATA jugaWestern Digital WD RE WD4000FYYZ
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
pada mesin yang terpengaruh. Saya berasumsi ini cukup dapat direproduksi sehingga Anda dapat mengamati sebelum / sesudah dengan pengaturan ini.Masalahnya jelas bukan masalah terkait disk. Dan ini jelas dari strace yang digantung:
/ 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$PID
mana ID proses tempat bacaan dibaca.Dalam kasus Anda, saya akan mulai dengan peningkatan kernel.
sumber
/proc/%d/cmdline
adalah bagian dari ruang alamat proses di mana kernel menyimpan baris perintah selamaexecve
panggilan. Seperti bagian lain dari ruang pengguna, ini dapat ditukar. Jadi mengaksesnya mungkin memang harus menunggu halaman untuk ditukar lagi.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.
sumber
Ini adalah perbaikan lain.
Sepertinya kita menjalankan pengontrol serangan berikut
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.
sumber