ps aux แขวนอยู่บน cpu / IO สูงด้วยกระบวนการจาวา

ฉันมีปัญหาบางอย่างกับกระบวนการจาวาและการตรวจสอบ nrpe เรามีกระบวนการบางอย่างที่บางครั้งใช้ CPU 1000% ในระบบ 32 คอร์ ระบบค่อนข้างตอบสนองจนกว่าคุณจะทำ

ps aux 

หรือลองทำอะไรก็ได้ใน / proc / pid # like

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

ความงดงามของ 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,

กระบวนการ java กำลังทำงานและจะเสร็จสมบูรณ์ แต่ปัญหาคือทำให้กระบวนการตรวจสอบถั่วของเราหยุดทำงานเนื่องจากหมดเวลารอ ps aux ให้เสร็จ

ฉันพยายามทำสิ่งที่ชอบ

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

โดยไม่มีโชค

แก้ไข

รายละเอียดระบบ

• 32 คอร์ Intel (R) Xeon (R) CPU E5-2650 0 @ 2.00GHz
• ram ขนาด 128 กรัม
• 12 ไดรฟ์ 4Tb 7200
• CentOS 6.5
• ฉันไม่แน่ใจรุ่น แต่ผู้ขายคือ SuperMicro

โหลดเมื่อเกิดเหตุการณ์นี้ประมาณ 90-160ish เป็นเวลา 1 นาที

ส่วนที่แปลกคือฉันสามารถไปที่อื่น / proc / pid # และทำงานได้ดี ระบบตอบสนองเมื่อฉัน ssh ระบบเหมือนเมื่อเราได้รับการแจ้งเตือนของการโหลดสูงฉันสามารถ ssh ได้ในดี

การแก้ไขอื่น

ฉันใช้กำหนดส่งงานกำหนดการแล้ว

[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

ภูเขาดูเหมือนว่า

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

โอเคฉันพยายามติดตั้งแบบปรับและตั้งค่าเป็นประสิทธิภาพของปริมาณงาน

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

โดยทั่วไปแล้วฉันเคยเห็นสิ่งนี้เกิดขึ้นเพราะการอ่านจนตรอก นี่คือการยืนยันจากstraceผลลัพธ์ของคุณ ความพยายามในการอ่าน / proc / xxxx / cmdline ไฟล์ค้างในขณะที่คุณกำลังเรียกใช้ps auxคำสั่ง

เดือยชั่วขณะใน I / O กำลังหิวโหยทรัพยากรของระบบ โหลด 90-160 เป็นข่าวร้ายอย่างยิ่งถ้าเกี่ยวข้องกับระบบย่อยของหน่วยเก็บข้อมูล

สำหรับอาร์เรย์หน่วยเก็บข้อมูลคุณสามารถบอกเราได้หรือไม่ว่ามีคอนโทรลเลอร์ RAID สำหรับฮาร์ดแวร์อยู่หรือไม่? แอปพลิเคชันหลักบนเซิร์ฟเวอร์เขียนลำเอียงหรือไม่ ดิสก์ที่คุณพูดถึง (12 x 4TB) เป็นดิสก์ SAS หรือ SATA ความเร็วต่ำใกล้เคียง หากไม่มีแคชรูปแบบการเขียนที่ด้านหน้าอาร์เรย์ของไดรฟ์การเขียนจะสามารถผลักระบบให้โหลดได้ หากสิ่งเหล่านี้เป็นไดรฟ์ SATA บริสุทธิ์บนแบ็คเพลน Supermicro อย่าลดความเป็นไปได้ของปัญหาดิสก์อื่น ๆ ( หมดเวลา, ไดร์ฟที่ล้มเหลว, แบ็คเพลน ฯลฯ ) สิ่งนี้เกิดขึ้นกับโหนด Hadoop ทั้งหมดหรือไม่

การทดสอบอย่างง่ายคือพยายามเรียกใช้iotopขณะที่เกิดเหตุการณ์นี้ขึ้น นอกจากนี้เนื่องจากนี่คือ EL6.5 คุณมีการtuned-admตั้งค่าใด ๆ ที่เปิดใช้งานหรือไม่ เปิดใช้งานอุปสรรคการเขียนหรือไม่

หากคุณไม่ได้เปลี่ยนลิฟท์ I / O ของเซิร์ฟเวอร์ioniceอาจมีผลกระทบ หากคุณเปลี่ยนเป็นอื่นนอกเหนือจากCFQ ( เซิร์ฟเวอร์นี้ควรจะอยู่ในกำหนดเวลา ) ioniceจะไม่สร้างความแตกต่าง

แก้ไข:

อีกสิ่งหนึ่งที่แปลกประหลาดที่ฉันเคยเห็นในสภาพแวดล้อมการผลิต นี่เป็นกระบวนการของ Java และฉันจะถือว่าพวกมันเป็นมัลติเธรดอย่างหนัก คุณเป็นอย่างไรกับ PID? เป็นสิ่งที่sysctlคุ้มค่าสำหรับkernel.pid_max ? ฉันเคยมีสถานการณ์ที่ฉันหมด PID มาก่อนและมีการโหลดสูง

นอกจากนี้คุณพูดถึงเคอร์เนลรุ่น2.6.32-358.23.2.el6.x86_64 เป็นเวลากว่าหนึ่งปีแล้วและเป็นส่วนหนึ่งของ CentOS 6.4 ที่วางจำหน่าย แต่เซิร์ฟเวอร์ที่เหลือของคุณคือ 6.5 คุณทำบัญชีดำไม่ได้อัพเดท kernel ใน yum.conf หรือไม่ คุณควรจะอยู่ในเคอร์เนล 2.6.32-431.xx หรือใหม่กว่าสำหรับระบบนั้น อาจจะมีปัญหากับ hugepages เคอร์เนลเก่าที่คุณมี หากคุณไม่สามารถเปลี่ยนเคอร์เนลได้ให้ลองปิดการใช้งานด้วย:

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

ปัญหาชัดเจนว่าไม่ใช่ปัญหาเกี่ยวกับดิสก์ และนี่คือที่ชัดเจนจาก strace แขวน:

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

/ proc เป็นส่วนต่อประสานระหว่างเคอร์เนลและ userspace มันไม่ได้สัมผัสดิสก์เลย หากบางสิ่งถูกแขวนคอการอ่านอาร์กิวเมนต์ของคำสั่งมักเป็นปัญหาเกี่ยวกับเคอร์เนลและไม่น่าจะเป็นที่เก็บข้อมูล ดูความคิดเห็น @kasperd

การโหลดเป็นเพียงผลข้างเคียงของปัญหาและจำนวนสูงไม่ได้บอกเรื่องราวทั้งหมด คุณสามารถมีเซิร์ฟเวอร์ที่มีโหลดสูงมากซึ่งแอปพลิเคชันทำงานโดยไม่มีข้อผิดพลาดใด ๆ

cat /proc/$PID/stackคุณสามารถได้รับข้อมูลเพิ่มเติมเกี่ยวกับสิ่งที่เกิดขึ้นกับ ที่ไหน$PIDเป็นกระบวนการ ID ที่อ่านแผงลอย

ในกรณีของคุณฉันจะเริ่มต้นด้วยการอัพเกรดเคอร์เนล

ดังนั้นแม้จะมีการปรับแต่งและอัปเกรดเป็นเคอร์เนล 2.6 ล่าสุดที่ CentOS ให้เรายังคงเห็นแฮงค์ ไม่มากเหมือน แต่ก่อน แต่ก็ยังเห็นพวกเขาอยู่

การแก้ไขคือการอัพเกรดเคอร์เนลซีรีส์ 3.10.x ที่ CentOS จัดเตรียมไว้ใน repos centosplus ของพวกเขาที่นี่

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

สิ่งนี้ได้หมดไปกับทรีกระบวนการแฮงค์ อย่างที่ฉันบอกว่าระบบไม่ได้อยู่ภายใต้ภาระที่บ้าคลั่งใด ๆ ที่การทำงานของกระบวนการใหม่ไม่ราบรื่น ดังนั้นส่วนใหญ่จะเป็นปัญหาเคอร์เนล 2.6 บางแห่ง

นี่คือการแก้ไขอื่น

ดูเหมือนว่าเรากำลังเรียกใช้ตัวควบคุมการโจมตีต่อไปนี้

Adaptec 71605

ฉันทำการอัปเดตเฟิร์มแวร์กับเครื่องที่ได้รับผลกระทบทั้งหมดเป็นเวอร์ชั่นล่าสุดและดูเหมือนว่าจะเป็นการแก้ไขปัญหา

เราต้องปรับลดรุ่นจากการทดสอบเคอร์เนล 3.10 เนื่องจากปัญหาสุ่มอื่น ๆ ที่ติดตั้ง 3.10 บน CentOS 6 แต่การอัพเกรดเฟิร์มแวร์ดูเหมือนว่าจะแก้ไขปัญหาได้