Chờ IO cao - Làm thế nào để xác định nguyên nhân gốc?


10

Tôi có một ví dụ MySQL trên hai máy chủ chuyên dụng. Một cho sản xuất, một cho nền tảng thử nghiệm.

Hai máy chủ khá giống nhau, sự khác biệt duy nhất là bộ điều khiển RAID và âm lượng ảo (HD là như nhau). Về sản xuất, có bộ điều khiển RAID RAID chuyên dụng và âm lượng RAID 10. Mặt khác, bộ điều khiển RAID dường như là phần mềm (Lenovo ThinkServer RAID 110i) và âm lượng là RAID 5.

Chúng tôi nhận thấy rằng trong quá trình MySQL cam kết, chúng tôi có iowait cao:

while true; do date; ps auxf | awk '{if($8=="D") print $0;}'; sleep 1; done
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:37 CEST 2015
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:38 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:39 CEST 2015
Thu Jun 18 13:49:40 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root      1478  0.0  0.0      0     0 ?        D    Jun04   0:03  \_ [jbd2/dm-7-8]
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]

dm-10-8 & dm-14-8 có liên quan đến phân vùng cơ sở dữ liệu.

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  3 240904 809656 572624 7114416    0    0    59  1681 2002 5141  3  1 67 30  0
 0  4 240880 809656 572632 7114604    0    0   139  2069 2090 4985  3  1 67 29  0
 1  2 240880 809284 572636 7114676    0    0    27  2159 2253 4247  2  1 72 25  0
 5  2 240880 809408 572656 7114820    0    0    27  2404 2254 5350  3  1 69 27  0

Tôi nghi ngờ bộ điều khiển đột kích, làm thế nào tôi có thể chắc chắn?


Có thể lạc đề: Nhưng tại sao RAID5 trên cơ sở dữ liệu? Ý tưởng tồi do khoảng cách viết. CTNH với BBU giảm nhẹ phần nào điều này, nhưng RAID 5 về cơ bản là tốt cho việc đọc, không phải để viết các giao dịch nhỏ.
Hennes

Bởi vì tôi không có lựa chọn nào ... RAID 10 không được hỗ trợ trên bộ điều khiển RAID này (với phiên bản RHEL của tôi) ...
Bob Sauvage

@BobSauvage có tiến triển gì không?
Huygens

chỉ cần rõ ràng: io-Wait có bao gồm cả việc chờ mô tả tệp không được cung cấp bởi bộ lưu trữ lớn không? như ổ cắm ...
Massimo

Câu trả lời:


7

Câu trả lời của tôi có 2 phần: điều tra trình điều khiển thiết bị khối; và tối ưu hóa đáng xem với trường hợp sử dụng của bạn. Nhưng tôi đã loại bỏ phần cuối cùng vì nó đã được báo cáo rằng nó có thể dẫn đến mất dữ liệu. Xem ý kiến.

Điều tra phần cứng

Tôi hiểu rằng với cùng một ứng dụng nhưng trên 2 bộ phần cứng khác nhau thì hiệu năng rất khác nhau và bạn muốn hiểu tại sao. Do đó, tôi đề xuất trước tiên một phương tiện để giúp bạn tìm câu trả lời cho "tại sao".

Về hiệu suất, tôi thường tham khảo Bản đồ hiệu suất Linux do Brendan Gregg cung cấp trên blog của mình. Người ta có thể thấy rằng ở mức độ thấp (gần nhất với phần cứng), một công cụ như thế blktracesẽ hoàn hảo.

Không thực sự biết công cụ này, tôi tìm kiếm xung quanh và tìm thấy bài viết thú vị này liên quan đến blktrace của Marc Brooker. Về cơ bản, nó gợi ý như sau: thực hiện theo dõi I / O bằng cách sử dụng blktrace; sử dụng công cụ btt để trích xuất thông tin từ dấu vết này. Đó sẽ là một cái gì đó như thế này (cho một dấu vết 30 giây):

# blktrace -w 30 -d /dev/dm-10-8 -o dm-10-8
# blkparse -d blkmerged.out dm-10-8*
# btt -i blkmerged.out | less

Đầu ra có thể khá dài, nhưng hãy tìm các mục D2C. Nó sẽ cho bạn ý tưởng về thời gian cần thiết cho một I / O được gửi đến trình điều khiển thiết bị để được báo cáo bởi trình điều khiển này.

Ví dụ đầu ra ( dnf upgradechạy trên VirtualBox VM trên máy tính xách tay bận rộn của tôi):

            ALL           MIN           AVG           MAX           N
--------------- ------------- ------------- ------------- -----------

...
D2C               0.000046515   0.045781696   3.940577359       11713
...

Nó cho thấy mức trung bình đáng thất vọng là 45 ms mỗi I / O với tối đa 3,94 giây cho trường hợp xấu nhất !!

Để biết thêm cách sử dụng blktrace để thực hiện điều tra này, hãy đọc bài viết từ Marc Brooker, rất hướng dẫn.


Bài đăng trên blog Percona được tham chiếu trong phần chỉnh sửa câu trả lời để cải thiện hiệu suất innodb đã được cập nhật với: Cập nhật: không làm điều này, điều này đã được chứng minh là dữ liệu bị hỏng!
vkats

@vkats cảm ơn rất nhiều. Tôi đã cập nhật câu trả lời để xóa đề xuất và bài viết.
Huygens

1

quá trình jbd2 là dành cho tạp chí ext4. Điều hợp lý là hệ thống tập tin cần phải ghi vào nhật ký trong khi cam kết mysql, đây không phải là lý do cho bất kỳ lo lắng nào. Lượng tải gây ra bởi jbd bị ảnh hưởng bởi các tham số gắn kết của bạn cho các phân vùng dm-10-8 và dm-14-8. Có lẽ rất mong muốn có một nhật ký rất bảo mật tại phân vùng cơ sở dữ liệu để đảm bảo rằng cơ sở dữ liệu của bạn không bị hỏng nếu có điều gì đó xảy ra và máy chủ của bạn vô tình khởi động lại. Bạn có thể chọn một tùy chọn gắn kết tạp chí khác trong môi trường thử nghiệm chỉ để so sánh.


jbd2 / dm-2-8 của tôi dường như lúc nào cũng khoảng 8,5% tại iotop, nhưng .. Tôi không nghĩ đó là vấn đề vì không có đĩa đọc và tổng số đĩa ghi là 35mb sau 1 giờ. btw, at / dev có nhiều nhất là dm-2 (đó là -8 tôi không biết nó đến từ đâu ..)
Sức mạnh của Bảo Bình
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.