Tải máy chủ cao - [jbd2 / md1-8] sử dụng 99,99% IO


11

Tôi đã tăng đột biến trong tuần qua. Điều này thường xảy ra một hoặc hai lần một ngày. Tôi đã quản lý để xác định từ iotop rằng [jbd2 / md1-8] đang sử dụng 99,99% IO. Trong thời gian tải cao, không có lưu lượng truy cập cao đến máy chủ.

Thông số kỹ thuật của máy chủ là:

  • AMD Opteron 8 lõi
  • RAM 16 GB
  • Phần mềm ổ cứng 2x2.000 GB 7.200 RPM Raid 1
  • Cloudlinux + Cpanel
  • Mysql được điều chỉnh đúng

Ngoài các gai, tải thường là khoảng 0,80.

Tôi đã tìm kiếm xung quanh nhưng không thể tìm thấy chính xác [jbd2 / md1-8]. Có ai có vấn đề này hoặc có ai biết một giải pháp có thể?

Cảm ơn bạn.

CẬP NHẬT:

TIME        TID     PRIO     USER    DISK READ    DISK WRITE    SWAPIN  IO       COMMAND
16:05:36     399     be/3    root    0.00 B/s      38.76 K/s    0.00 %  99.99 %  [jbd2/md1-8]

1
vi.wikipedia.org/wiki/Journaling_block_device & linux.die.net/man/4/md chỉ ra điều này có liên quan đến phần mềm RAID.
mbrownnyc

Cảm ơn vì đã trả lời. Sau khi thực hiện một số hoạt động đào, tôi thấy rằng nó có liên quan đến RAID phần mềm. Bạn có biết giải pháp nào cho nó không? Điều kỳ lạ là nó bắt đầu xảy ra chỉ một tuần trước, sau gần 3 tháng không có vấn đề gì.
Alex

Làm thế nào bạn xác định IO là 99,99%? Bạn đã sử dụng iostat? Bạn có thể chạy một chút trong số đó (nói iostat 5) một chút và chia sẻ đầu ra không?
slm

Tôi đã kích hoạt đăng nhập cho iotop và xem nhật ký cho khoảng thời gian tải xảy ra. Bây giờ tải thấp nên không có điểm nào để chạy ngay bây giờ, nhưng tôi sẽ thực hiện nó vào lần tiếp theo. Cảm ơn vì đã trả lời.
Alex

1
Tôi chỉ gặp vấn đề chính xác này. Giải pháp cuối cùng của bạn là gì?
Satanicpuppy

Câu trả lời:


17

Đây thực sự không phải là một câu trả lời vì không có đủ ngữ cảnh để đưa ra nguyên nhân chính xác, nhưng nó là một mô tả về cách tôi quản lý để theo dõi điều này khi nó xảy ra với tôi.

Tôi nhận thấy tôi jbd2/md0-8tiếp tục xuất hiện ở đầu iotop. Tôi nhìn vào /sys/kernel/debug/tracing/events/jbd2để xem có những lựa chọn nào để xác định những gì jbd2đang làm.

LƯU Ý-1: Để xem đầu ra cho các sự kiện theo dõi gỡ lỗi cat /sys/kernel/debug/tracing/trace_pipe- Tôi đã chạy nó trong thiết bị đầu cuối trong khi bật / tắt các dấu vết.

CHÚ THÍCH-2: Để cho phép các sự kiện truy tìm sử dụng, vd echo 1 > /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable. Để vô hiệu hóa echo 0 > /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable.

Tôi đã bắt đầu bằng cách kích hoạt /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable- nhưng không có gì có vẻ đặc biệt thú vị trong đầu ra cho nó. Tôi đã thử một vài sự kiện khác để theo dõi và khi tôi bật /sys/kernel/debug/tracing/events/jbd2/jbd2_commit_flushing/enabletôi thấy nó xảy ra mỗi giây:

# cat /sys/kernel/debug/tracing/trace_pipe
...
jbd2/md0-8-2520  [004] .... 658660.216492: jbd2_commit_flushing: dev 9,0 transaction 32856413 sync 0
jbd2/md0-8-2520  [001] .... 658661.334900: jbd2_commit_flushing: dev 9,0 transaction 32856414 sync 0
jbd2/md0-8-2520  [001] .... 658661.394113: jbd2_commit_flushing: dev 9,0 transaction 32856415 sync 0

Điều này trông giống như nó có liên quan đến sync(2)/ fsync(2)/ msync(2), vì vậy tôi đã tìm một số cách để liên kết điều này với một quá trình và tìm thấy điều này:

# find /sys/kernel/debug/tracing/events/ | grep sync.*enable
...
/sys/kernel/debug/tracing/events/ext4/ext4_sync_file_enter/enable
...

Khi tôi kích hoạt, tôi thấy đầu ra sau:

# cat /sys/kernel/debug/tracing/trace_pipe
...
      nzbget-17367 [002] .... 658693.222288: ext4_sync_file_enter: dev 9,0 ino 301924373 parent 301924357 datasync 1 
  jbd2/md0-8-2520  [001] .... 658693.284080: jbd2_commit_flushing: dev 9,0 transaction 32856465 sync 0
      nzbget-17367 [000] .... 658693.334267: ext4_sync_file_enter: dev 9,0 ino 301924357 parent 301924353 datasync 1 
  jbd2/md0-8-2520  [002] .... 658693.334275: jbd2_commit_flushing: dev 9,0 transaction 32856466 sync 0
      nzbget-17367 [001] .... 658694.369514: ext4_sync_file_enter: dev 9,0 ino 301924367 parent 301924357 datasync 1 
  jbd2/md0-8-2520  [002] .... 658694.414861: jbd2_commit_flushing: dev 9,0 transaction 32856467 sync 0
      nzbget-17367 [001] .... 658694.470872: ext4_sync_file_enter: dev 9,0 ino 301924357 parent 301924353 datasync 1 
  jbd2/md0-8-2520  [002] .... 658694.470880: jbd2_commit_flushing: dev 9,0 transaction 32856468 sync 0

Điều này đã cho tôi tên quy trình / id - và sau khi thực hiện thêm một số sửa lỗi của quy trình này ( nzbget) tôi phát hiện ra nó đang thực hiện fsync(2)mỗi giây. Sau khi tôi thay đổi cấu hình của nó ( FlushQueue=notôi nghĩ là không có giấy tờ, đã tìm thấy nó trong nguồn) để ngăn nó thực hiện điều này mỗi giây fsync(2), vấn đề đã biến mất.

Phiên bản kernel của tôi là. 4.4.6-gentooTôi nghĩ rằng có một số tùy chọn tôi đã bật (bằng tay hoặc bằng make oldconfig) tại một số điểm trong cấu hình kernel để có được /sys/kernel/debugcác sự kiện này - vì vậy nếu bạn không có nó, có thể chỉ cần tìm trên internet để biết thêm thông tin về việc bật nó


Đẹp điều tra. Điều này rất hữu ích.
jdhildeb

Cảm ơn rất nhiều vì đã chi tiết tất cả quá trình!
astrojuanlu

1

Đây có vẻ là một điều cập nhật tạp chí liên quan. Có bao nhiêu đĩa là phần mềm RAID được tạo thành. Bạn có thể chỉ cho tôi lệnh được sử dụng để tạo ra nó.

Bạn cũng có thể pastebin đầu ra dumpe2fs. Đầu tiên, xác định thiết bị vật lý nơi bạn thấy tải. Sử dụng df để biết điều này. Sau đó,

dumpe2fs /dev/sdaX > /tmp/dump

Đối với trường hợp của bạn, nó có thể là / dev / md0.

Ngoài ra, chạy này.

iostat -xdk 1 25

Tại thời điểm vấn đề IO cao.

Tôi không biết cloudlinux nhưng là công cụ blktrace có sẵn bên dưới nó.


Xin chào Soham, cảm ơn bạn đã trả lời. Có 2 đĩa trong mảng. Đối với dumpe2fs, bạn có thể vui lòng cho tôi lệnh đầy đủ mà bạn muốn tôi chạy không? Cảm ơn đã giúp đỡ.
Alex

Alex, chỉnh sửa câu trả lời.
Soham Chakraborty

Không bao giờ quên chiếc mũ này thực sự không phải là bất kỳ thiết lập perforamnce nào từ các đĩa - "chậm như một máy trạm" mô tả nhiều hơn về nó.
TomTom
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.