Làm cách nào tôi có thể ngăn [flush-8: 16] và [jbd2 / sdb2-8] gây ra phản ứng GUI? [đóng cửa]


11

Khoảng hai lần một tuần, toàn bộ giao diện đồ họa sẽ khóa trong khoảng 10-20 giây mà không có cảnh báo trong khi tôi đang thực hiện các tác vụ đơn giản như duyệt web hoặc viết giấy. Khi điều này xảy ra, các thành phần GUI không phản hồi với đầu vào chuột hoặc bàn phím và applet System Monitor hiển thị 100% sử dụng bộ xử lý IOWait.

Hôm nay, cuối cùng tôi đã tình cờ có Thiết bị đầu cuối Gnome đã mở khi sự cố bắt đầu. Mặc dù các ứng dụng khác như Google Chrome, Firefox, Gnome Do và Bảng điều khiển Gnome không phản hồi, thiết bị đầu cuối có thể sử dụng được. Tôi đã chạy iotopvà quan sát thấy các lệnh được đặt tên [flush-8:16][jbd2/sdb2-8]luân phiên sử dụng 99,99% IO.

Đây là những gì và làm cách nào tôi có thể ngăn chúng gây ra sự không phản hồi GUI?

Chi tiết

$ 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/sdalà một OCZ-VERTEX2/dev/sdbWD10 YearsS . Đây là dumpe2fs /dev/sdb2smartctl /dev/sdb --all.

Tôi không thấy bất cứ điều gì bất thường trong dmesghoặc /var/log/syslog.


1
Tôi có thể cho bạn biết chúng là gì: Chúng là một phần của hệ thống tệp - flushghi bộ đệm / bộ đệm RAM vào đĩa và jbd2 xử lý tạp chí ext4.
jg-faustus

Đây có phải là một máy tính xách tay không?
jg-faustus

Chỉ cần suy nghĩ lớn ở đây: 100% IOWait có thể có nghĩa là hệ thống tệp đang chờ đĩa thoát khỏi trạng thái năng lượng thấp - tiết kiệm năng lượng áp lực là một tính năng chính của WD Greens. Nhưng không chắc chắn tại sao nó sẽ khóa hệ thống. Có lẽ cũng có một cái /dev/sda- đĩa nào chứa cái gì? Giống như "root trên sda, home trên sdb"?
jg-faustus

Có thể là một đĩa xấu, kiểm tra dữ liệu SMART hoặc đầu ra dmesgcho các lỗi đĩa.
sắp xếp

4
"quá cục bộ" - thật tệ khi tôi là một khách truy cập trong tương lai đã tìm thấy câu hỏi này bởi vì tôi đang xem xét chính xác cùng một vấn đề.
DXM

Câu trả lời:


4

Tôi sẽ mạo hiểm một lý thuyết:

/dev/sdb1 có lẽ là trao đổi không gian?

Nếu một cái gì đó trung tâm của giao diện đồ họa đã được giảm tải vào đĩa, GUI không thể tiếp tục cho đến khi nhận được những dữ liệu đó. Nếu đĩa trao đổi đang ngủ, điều này có nghĩa là nó bị kẹt cho đến khi đĩa phản hồi.

Tôi nghĩ rằng điều này sẽ tạm thời bị khóa và khoảng thời gian 10-20 giây phù hợp với thời gian cần thiết để đĩa ngủ phản hồi. Thiết bị đầu cuối có lẽ vẫn đáp ứng vì tất cả những gì nó cần đã có trong RAM.

Một số công cụ đầu cuối để khám phá lý thuyết:

  • hdparm -C /dev/sdX cho bạn biết đĩa có đang ngủ hay không:

    $ sudo hdparm -C /dev/sdb
    /dev/sdb:
    drive state is:  standby
    

    active/idlecó nghĩa là nó đang chạy. Ở trạng thái standbyhoặc sleepingnó đã ngừng quay và sẽ mất một lúc để bắt đầu lại. Xem man hdparm.

  • free -m cho biết bao nhiêu không gian hoán đổi được sử dụng:

    $ free -m     
                 total       used       free     [...]
    Mem:          5973       4928       1045     [...]
    -/+ buffers/cache:       1091       4882
    Swap:         6234          0       6234
    

    "Hoán đổi:" là dòng có liên quan, trong ví dụ này, trao đổi 6.2 GB có sẵn và không có gì được sử dụng.

Nếu đây là vấn đề, bạn có thể chuyển hoán đổi sang sda hoặc vô hiệu hóa spindowns cho sdb.


Đây là một lý thuyết tốt, nhưng tôi nghĩ vấn đề không liên quan đến trao đổi. Mặc dù phân vùng trao đổi thực sự nằm trên cùng một ổ đĩa, nhưng hệ thống hiếm khi sử dụng nó. free -mtrong quá trình khóa xác nhận rằng 0 MB trao đổi đã được sử dụng.
ændrük

@ ndrük Ok, sau đó tôi sẽ phải rời khỏi lĩnh vực này để các chuyên gia.
jg-faustus
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.