เซิร์ฟเวอร์ที่โหลดสูงอาจทำให้เกิดการค้างและข้อผิดพลาด“ ถูกบล็อกนานกว่า 120 วินาที”

กำลังใช้งานเซิร์ฟเวอร์ VM และ 'baremetal' สองสามเครื่อง Java ทำงานบนที่สูง - มากกว่า 400% + ในบางครั้ง เซิร์ฟเวอร์สุ่มค้างกับข้อผิดพลาดในคอนโซล "java - ถูกบล็อคนานกว่า 120 วินาที" - kjournald เป็นต้น

ฉันไม่สามารถรับเอาต์พุต dmesg ได้ด้วยเหตุผลบางประการข้อผิดพลาดนี้จะเขียนไปยังคอนโซลซึ่งฉันไม่สามารถเข้าถึงได้เนื่องจากนี่โฮสต์จากระยะไกล ดังนั้นฉันไม่สามารถคัดลอกการติดตามแบบเต็ม

ฉันเปลี่ยนสภาพแวดล้อมที่เปิดอยู่แม้กระทั่งเซิร์ฟเวอร์จริงและก็ยังเกิดขึ้นอยู่

ผมเปลี่ยน hung_task_timeout_secs 0 กรณีนี้เป็นเท็จบวกตามhttp://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/deployment.html

นอกจากนี้ยังไม่ได้ติดตั้ง irqbalance บางทีมันอาจจะช่วยได้?

นี่คือ Ubuntu 10.04 64 บิต - ปัญหาเดียวกันกับเซิร์ฟเวอร์ 2.6.38-15 ล่าสุดและ 2.6.36

cpu หรือปัญหาหน่วยความจำ / ไม่มีการสลับซ้ายทำให้เกิดปัญหานี้หรือไม่?

นี่คือข้อความคอนโซล:

[58Z?Z1.5?Z840] INFUI task java:21547 blocked for more than 120 seconds.
[58Z?Z1.5?Z986] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?Z06Z] INFUI task kjournald:190 blocked for more than 120 seconds.
[58Z841.5?Z336] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?Z600] INFUI task flush-202:0:709 blocked for more than 120 seconds.
[58Z841.5?Z90?] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?3413] INFUI task java:21547 blocked for more than 120 seconds.
[58Z841.5?368Z] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z961.5?ZZ36] INFUI task kjournald:60 blocked for more than 120 seconds.
[58Z961.5?Z6Z5] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z961.5?31ZZ] INFUI task flush-202:0:709 blocked for more than 120 seconds.
[58Z961.5?3393] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.

ใช่มันทำได้

สิ่งนี้หมายความว่าค่อนข้างชัดเจน: เคอร์เนลไม่สามารถกำหนดเวลางานเป็นเวลา 120 วินาที สิ่งนี้บ่งชี้ถึงความอดอยากของทรัพยากรซึ่งมักเกิดจากการเข้าถึงดิสก์

irqbalanceอาจช่วยได้ แต่นั่นฟังดูไม่ชัดเจน คุณช่วยให้เรามีรอบของข้อความนี้dmesgโดยเฉพาะอย่างยิ่งการติดตามสแต็คที่ตามมาหรือไม่

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

สิ่งนี้ไม่สามารถเกิดจาก:

• ปัญหาซีพียู (หรือมากกว่านั้นจะเป็นความล้มเหลวของฮาร์ดแวร์ที่ไม่น่าจะเป็นไปไม่ได้)
• ปัญหาหน่วยความจำ (เป็นไปไม่ได้มากที่ฮาร์ดแวร์จะล้มเหลว แต่จะไม่เกิดขึ้นหลายครั้งไม่ขาด RAM ตามกระบวนการoom-killed)
• ขาดการแลกเปลี่ยน ( oom-killerอีกครั้ง)

หากต้องการขยายคุณอาจตำหนิได้หากขาดหน่วยความจำในแง่ที่ทำให้ระบบการแคชข้อมูลใน RAM ของคุณไม่เพียงพอจะทำให้ I / O มากขึ้น แต่มันก็ไม่ได้ตรงไปตรงมาเหมือน "หน่วยความจำไม่เพียงพอ"

sudo sysctl -w vm.dirty_ratio=10
sudo sysctl -w vm.dirty_background_ratio=5

จากนั้นส่งการเปลี่ยนแปลงด้วย:

sudo sysctl -p

แก้ไขให้ฉัน ....

ฉันเพิ่งพบข้อผิดพลาดนี้ในหนึ่งในกลุ่มการผลิตของเรา:

11 พ.ย. 14:56:41 xxx เคอร์เนล: INFO: task xfsalloc / 3: 2393 ถูกบล็อคนานกว่า 120 วินาที

11 พฤศจิกายน 14:56:41 Xxxx เคอร์เนล: ไม่บริสุทธิ์ 2.6.32-504.8.1.el6.x86_64 # 1

11 พ.ย. 14:56:41 xxx: "echo 0> / proc / sys / kernel / hung_task_timeout_secs" ปิดใช้งานข้อความนี้

..

ในการตรวจสอบเพิ่มเติมของบันทึก sar พบว่าการรอ IO เพิ่มขึ้นในช่วงเวลาเดียวกัน

และเมื่อตรวจสอบฮาร์ดแวร์ (ดิสก์ทางกายภาพ) เห็นข้อผิดพลาดขนาดกลางและข้อผิดพลาด SCSI อื่น ๆ ได้เข้าสู่ระบบหนึ่งดิสก์ทางกายภาพซึ่งในทางกลับกันคือการปิดกั้น IOs เนื่องจากขาดทรัพยากรในการจัดสรร

11/11/15 19:52:40: สิ้นสุด pRdm 607b8000 ค่าสถานะ = 0 TimeOutC = 0 RetryC = 0 ร้องขอ c1173100 ตอบกลับ 60e06040 iocStatus 0048 retryC 0 devId: 3 devFlags = f1482005 iocLogInfo: 31140000

11/11/15 19:52:40: DM_ProcessDevWaitQueue: งาน mgmt ในกระบวนการ devId = x 11/11/15 19:52:40: DM_ProcessDevWaitQueue: งาน mgmt ในกระบวนการ devId = x

ดังนั้นนี่เป็นเพราะข้อผิดพลาดของฮาร์ดแวร์ในคลัสเตอร์ของเรา

ดังนั้นมันจะดีถ้าคุณสามารถตรวจสอบไฟล์ core และถ้ามีโปรแกรมอรรถประโยชน์ ipmi อยู่ให้ตรวจสอบคำสั่ง ipmiutil / ipmitool sel elist เพื่อตรวจสอบปัญหา

ขอแสดงความนับถือ VT

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