ฉันจะป้องกันไม่ให้ [flush-8: 16] และ [jbd2 / sdb2-8] ทำให้ GUI ไม่ตอบสนองได้อย่างไร [ปิด]

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

ปิดให้บริการใน8 ปีที่ผ่านมา

ประมาณสองครั้งต่อสัปดาห์อินเทอร์เฟซแบบกราฟิกทั้งหมดจะล็อกประมาณ 10-20 วินาทีโดยไม่มีการเตือนในขณะที่ฉันกำลังทำงานง่าย ๆ เช่นการท่องเว็บหรือเขียนกระดาษ เมื่อสิ่งนี้เกิดขึ้นองค์ประกอบ GUI จะไม่ตอบสนองต่อเมาส์หรือคีย์บอร์ดและแอปเพล็ตการตรวจสอบระบบแสดงการใช้งานตัวประมวลผล IOWait 100%

วันนี้ในที่สุดฉันก็พบว่าเทอร์มินัล GNOME เปิดขึ้นเมื่อปัญหาเริ่มขึ้น แม้จะมีแอปพลิเคชันอื่น ๆ เช่น Google Chrome, Firefox, GNOME Do และ GNOME Panel ไม่ตอบสนอง แต่เทอร์มินัลก็สามารถใช้งานได้ ฉันวิ่งiotopและสังเกตว่าคำสั่งตั้งชื่อ[flush-8:16]และ[jbd2/sdb2-8]สลับกันโดยใช้ 99.99% IO

สิ่งเหล่านี้คืออะไรและฉันจะป้องกันไม่ให้ GUI ไม่ตอบสนองได้อย่างไร

รายละเอียด

$ mount | grep ^/dev
/dev/sda1 on / type ext4 (rw,noatime,discard,errors=remount-ro,commit=0)
/dev/sdb2 on /home type ext4 (rw,commit=0)
$ cat /proc/swaps 
Filename        Type        Size     Used    Priority
/dev/sdb3       partition   1052252  0       -1

/dev/sdaเป็นOCZ-VERTEX2และ/dev/sdbเป็นWD10EARS นี่คือdumpe2fs /dev/sdb2และsmartctl /dev/sdb --all.

ฉันไม่เห็นอะไรผิดปกติในหรือdmesg/var/log/syslog

cpu-load disk-usage

— ændrük
แหล่งที่มา

ฉันสามารถบอกคุณได้ว่าพวกเขาคืออะไร: พวกเขาเป็นส่วนหนึ่งของระบบไฟล์ - flushเขียน RAM buffer / cache ไปยังดิสก์และ jbd2 เกี่ยวข้องกับ ext4 journal

— jg-faustus

นี่เป็นแล็ปท็อปใช่มั้ย

— jg-faustus

แค่คิดออกมาดัง ๆ ที่นี่: 100% IOWait อาจหมายความว่าระบบไฟล์กำลังรอให้ดิสก์ปลุกจากสถานะพลังงานต่ำ - การประหยัดพลังงานแบบก้าวร้าวเป็นคุณสมบัติหลักของ WD Greens แต่ไม่แน่ใจว่าทำไมมันถึงล็อคระบบ มีสมมุติ/dev/sdaเช่นกัน - ดิสก์ใดเก็บอะไร ชอบ "root on sda, home on sdb" หรือไม่

— jg-faustus

อาจเป็นดิสก์ที่ไม่ดีตรวจสอบข้อมูล SMART หรือผลลัพธ์ของdmesgข้อผิดพลาดของดิสก์

— จัด

"แปลเป็นภาษาท้องถิ่นเกินไป" - แย่มากที่ฉันเป็นผู้เยี่ยมชมในอนาคตที่พบคำถามนี้เพราะฉันกำลังดูปัญหาเดียวกันทั้งหมด

— DXM

ฉันจะร่วมทฤษฎี

/dev/sdb1 อาจจะเป็นพื้นที่แลกเปลี่ยน

หากสิ่งที่เป็นศูนย์กลางของอินเทอร์เฟซแบบกราฟิกถูกถ่ายลงในดิสก์ GUI ไม่สามารถดำเนินการต่อไปจนกว่าจะได้รับข้อมูลเหล่านั้น หากดิสก์แลกเปลี่ยนกำลังสลีปแสดงว่าติดอยู่จนกระทั่งดิสก์ตอบสนอง

ฉันคิดว่านี่จะให้การล็อคชั่วคราวและช่วงเวลา 10-20 วินาทีนั้นเหมาะกับเวลาที่ดิสก์การตอบสนอง เทอร์มินัลนั้นยังคงตอบสนองได้ดีเพราะสิ่งที่มันต้องการมีอยู่ใน RAM แล้ว

เครื่องมือเทอร์มินัลเพื่อสำรวจทฤษฎี:

hdparm -C /dev/sdX บอกคุณว่าดิสก์กำลังหลับหรือไม่:
```
$ sudo hdparm -C /dev/sdb
/dev/sdb:
drive state is:  standby
```
active/idleหมายความว่ามันกำลังทำงานอยู่ อยู่ในสถานะหยุดทำงานstandbyหรือsleepingหยุดหมุนและจะใช้เวลาสักครู่ในการเริ่มต้นใหม่อีกครั้ง man hdparmดู
free -m บอกว่าใช้พื้นที่สว็อปเท่าใด:
```
$ free -m     
             total       used       free     [...]
Mem:          5973       4928       1045     [...]
-/+ buffers/cache:       1091       4882
Swap:         6234          0       6234
```
"Swap:" เป็นบรรทัดที่เกี่ยวข้องในตัวอย่างนี้มีการแลกเปลี่ยน 6.2 GB และไม่มีอะไรใช้

หากนี่เป็นปัญหาคุณสามารถย้าย swap ไปยัง sda หรือปิดการใช้งาน spindowns สำหรับ sdb

— JG-เฟาสตุส
แหล่งที่มา

นี่เป็นทฤษฎีที่ดี แต่ฉันคิดว่าปัญหาไม่เกี่ยวข้องกับการแลกเปลี่ยน ในขณะที่พาร์ติชั่น swap นั้นอยู่ในไดรฟ์เดียวกันระบบจะใช้มันน้อยมาก free -mในระหว่างการล็อกยืนยันว่ามีการใช้การแลกเปลี่ยน 0 MB

— ændrük

@ ændrükตกลงแล้วฉันจะต้องออกจากสนามไปยังผู้เชี่ยวชาญ

— jg-faustus