Giám sát hiệu quả MySQL với Bảng điều khiển SCUMM:Phần 3

Chúng tôi đã thảo luận trong các blog trước đây của chúng tôi về các bảng điều khiển liên quan đến MySQL. Chúng tôi đã nêu bật những điều mà một DBA có thể hưởng lợi từ việc nghiên cứu các biểu đồ, đặc biệt là khi thực hiện các quy trình hàng ngày của họ từ chẩn đoán, báo cáo chỉ số và lập kế hoạch năng lực. Trong blog này, chúng ta sẽ thảo luận về Chỉ số InnoDB và Lược đồ hiệu suất MySQL, điều này rất quan trọng, đặc biệt là trong việc giám sát các giao dịch InnoDB, I / O đĩa / cpu / bộ nhớ, tối ưu hóa truy vấn của bạn hoặc điều chỉnh hiệu suất của máy chủ.

Blog này đề cập đến chủ đề sâu sắc về hiệu suất, xem xét rằng InnoDB sẽ yêu cầu phạm vi bảo hiểm rộng rãi nếu chúng tôi giải quyết nội bộ của nó. Lược đồ Hiệu suất cũng rất rộng rãi vì nó bao gồm hạt nhân và các phần cốt lõi của MySQL và các công cụ lưu trữ.

Hãy bắt đầu xem qua các biểu đồ.

Số liệu MySQL InnoDB

Bảng điều khiển này rất tuyệt vời cho bất kỳ người làm việc hoặc nhân viên MySQL DBA nào, vì nó cung cấp một cái nhìn rất tốt về công cụ lưu trữ InnoDB. Có một số biểu đồ nhất định ở đây mà người dùng phải xem xét để kích hoạt, bởi vì không phải trong tất cả các trường hợp, các biến được đặt chính xác trong cấu hình MySQL.

Tuổi của điểm kiểm tra Innodb

Theo hướng dẫn sử dụng, điểm kiểm tra được định nghĩa như sau:“ Khi các thay đổi được thực hiện đối với các trang dữ liệu được lưu vào bộ nhớ đệm trong vùng đệm , những thay đổi đó được ghi vào tệp dữ liệu một thời gian sau, một quá trình được gọi là tuôn ra . Điểm kiểm tra là bản ghi những thay đổi mới nhất (được biểu thị bằng LSN giá trị) đã được ghi thành công vào tệp dữ liệu ”. Biểu đồ này hữu ích khi bạn muốn xác định cách máy chủ của bạn thực hiện kiểm tra dữ liệu vào đĩa của bạn. Đây có thể là một tham chiếu tốt nếu nhật ký giao dịch của bạn (nhật ký làm lại hoặc ib_logfile0) quá lớn. Biểu đồ này cũng là một chỉ báo tốt nếu bạn cần điều chỉnh các biến như innodb_log_file_size ,, innodb_log_buffer_size, innodb_max_dirty_pages_pct hoặc innodb_adaptive_flushing_method. Tuổi của điểm kiểm tra càng gần với độ tuổi của điểm kiểm tra tối đa, nhật ký càng được lấp đầy và InnoDB sẽ thực hiện nhiều I / O hơn để duy trì một số không gian trống trong nhật ký. Cơ chế kiểm tra khác nhau ở các chi tiết tinh tế giữa các phiên bản dựa trên Percona XtraDB, MariaDB và phiên bản của Oracle, bạn cũng có thể tìm thấy sự khác biệt trong việc triển khai nó giữa các phiên bản MySQL.
Giao dịch InnoDB

Bất cứ khi nào có một giao dịch lớn đang diễn ra trong máy chủ MySQL của bạn, biểu đồ này là một tham chiếu tốt. Nó sẽ đếm các giao dịch đã được tạo tại một thời điểm cụ thể và độ dài lịch sử (hoặc thực tế là độ dài danh sách lịch sử được tìm thấy trong TÌNH TRẠNG KỸ THUẬT SHOW ENGINE INNODB) là số trang trong nhật ký hoàn tác. Các xu hướng bạn sẽ thấy ở đây là một nguồn tốt để kiểm tra xem nó có thể có nghĩa là, ví dụ:quá trình thanh lọc bị trì hoãn do tốc độ chèn tải lại dữ liệu rất cao hoặc do một giao dịch đang diễn ra trong thời gian dài hoặc nếu quá trình thanh lọc đơn giản có thể không theo kịp do I / O ổ đĩa cao trong ổ nơi $ DATADIR của bạn cư trú.
Hoạt động hàng Innodb

Đối với các tác vụ DBA nhất định, bạn có thể muốn xác định số lần xóa, số lần chèn, số lần đọc và số hàng được cập nhật. Sau đó, biểu đồ này là những gì bạn có thể sử dụng để kiểm tra những điều này.
Thời gian khóa hàng Innodb

Biểu đồ này là một tài nguyên tốt để xem xét khi bạn nhận thấy rằng ứng dụng của bạn đang gặp phải rất nhiều trường hợp “vượt quá thời gian chờ khóa; thử bắt đầu lại giao dịch ”. Điều này cũng có thể giúp bạn xác định xem bạn có thể có dấu hiệu cho việc sử dụng các truy vấn không hợp lệ để xử lý khóa hay không. Đây cũng là một tham chiếu tốt để xem xét khi tối ưu hóa các truy vấn của bạn liên quan đến việc khóa các hàng. Nếu thời gian chờ quá cao, bạn cần kiểm tra nhật ký truy vấn chậm hoặc chạy pt-query-thông báo và xem những truy vấn đáng ngờ nào gây ra hiện tượng phình ra đó trong biểu đồ.
I / O InnoDB

Bất cứ khi nào bạn muốn xác định số lượng dữ liệu InnoDB đọc, đĩa lưu trữ, ghi và ghi nhật ký, biểu đồ này có những gì bạn cần xem xét. Bạn có thể sử dụng biểu đồ này để xác định xem các biến InnoDB của bạn có được điều chỉnh tốt để xử lý các yêu cầu cụ thể của bạn hay không. Ví dụ:nếu bạn có bộ nhớ cache của Mô-đun dự phòng pin nhưng bạn không đạt được nhiều hiệu suất tối ưu, bạn có thể dựa vào biểu đồ này để xác định xem fsync () của bạn có cao hơn mong đợi hay không. Sau đó, thay đổi biến innodb_flush_method và sử dụng O_DSYNC có thể giải quyết vấn đề.
Sử dụng tệp nhật ký InnoDB hàng giờ

Biểu đồ này chỉ hiển thị số byte được ghi vào tệp nhật ký làm lại InnoDB và sự phát triển của tệp nhật ký InnoDB của bạn dựa trên phạm vi thời gian 24 giờ của ngày hiện tại.
Hiệu suất ghi nhật ký InnoDB

Đồ thị này có liên quan chặt chẽ đến đồ thị Hàng giờ sử dụng tệp nhật ký của InnoDB. Bạn phải sử dụng biểu đồ này bất cứ khi nào bạn cần xác định kích thước innodb_log_file_size của bạn cần phải lớn như thế nào. Bạn có thể xác định số byte được ghi vào tệp nhật ký làm lại InnoDB và cách MySQL của bạn chuyển dữ liệu từ bộ nhớ sang đĩa hiệu quả như thế nào. Bất cứ khi nào bạn gặp phải tình trạng sắp hết thời gian cần sử dụng không gian nhật ký làm lại của mình, thì điều đó sẽ cho thấy rằng bạn phải tăng kích thước tệp innodb_log_file của mình. Trong trường hợp đó, biểu đồ này sẽ cho bạn biết rằng bạn cần phải làm như vậy. Tuy nhiên, để tìm hiểu thêm về số lượng bạn cần cho innodb_log_file của mình, có thể hợp lý hơn khi kiểm tra LSN (Số thứ tự nhật ký) trong SHOW ENGINE INNODB STATUS. Percona có một blog tốt liên quan đến điều này, đây là một nguồn tốt để xem.
Các bế tắc của InnoDB

Trong một số tình huống nhất định mà ứng dụng khách của bạn thường gặp phải deadlock hoặc bạn phải xem mức độ mà MySQL của bạn đang gặp phải deadlock, biểu đồ này phục vụ cho mục đích này. Các deadlock cho thấy rằng bạn có thiết kế SQL kém, dẫn đến các giao dịch của bạn tạo ra một tình trạng chạy đua gây ra deadlock.

Đẩy xuống điều kiện lập chỉ mục

Một lời cảnh báo nhỏ khi nhìn vào biểu đồ này. Trước tiên, bạn phải xác định rằng bạn đã đặt biến toàn cục MySQL innodb_monitor_enable thành giá trị chính xác là module_icp. Nếu không, bạn sẽ gặp phải "Không có điểm dữ liệu" như được hiển thị bên dưới:

Mục đích của biểu đồ, nếu có các điểm dữ liệu được xác định như những gì tôi có trong kết quả đầu ra mẫu, sẽ cung cấp cho DBA cái nhìn về mức độ lợi ích của các truy vấn của bạn với Điều kiện chỉ mục Đẩy xuống hoặc viết tắt là ICP. ICP là một tính năng tuyệt vời trong MySQL giúp tối ưu hóa các truy vấn của bạn. Thay vì MySQL đọc các hàng đầy đủ được lọc trong các truy vấn WHERE của bạn khi truy xuất, nó sẽ thêm nhiều lần kiểm tra hơn sau các chỉ mục phụ của bạn. Điều này thêm chi tiết hơn và tiết kiệm thời gian, nếu không, thay vào đó, công cụ phải đọc các hàng trong bảng đầy đủ khi nó chỉ dựa trên chỉ mục đã lọc và không có ICP nào được sử dụng. Điều này tránh việc đọc các hàng đầy đủ tương ứng với các bộ chỉ mục khớp với các chỉ mục phụ của bạn.

Hãy để tôi giải thích một chút về biểu đồ này, giả sử tôi có một bảng có tên:

mysql> show create table a\G
*************************** 1. row ***************************
       Table: a
Create Table: CREATE TABLE `a` (
  `id` int(11) NOT NULL,
  `age` int(11) NOT NULL,
  KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

Và có một số dữ liệu nhỏ:

mysql> select * from a;
+----+-----+
| id | age |
+----+-----+
|  1 |   1 |
|  2 |   1 |
|  3 |   1 |
|  3 |  41 |
|  4 |  41 |
|  5 |   4 |
|  4 |   4 |
|  4 |   4 |
+----+-----+
8 rows in set (0.00 sec)

Khi bật ICP, kết quả sẽ hiệu quả và khả thi hơn:

mysql> explain extended select * from a where id>2 and id<4 and age=41;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra                              |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
|  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using index condition; Using where |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
1 row in set, 2 warnings (0.00 sec)

Hơn không có ICP,

mysql> set optimizer_switch='index_condition_pushdown=off';
Query OK, 0 rows affected (0.00 sec)

mysql> explain extended select * from a where id>2 and id<4 and age=41;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using where |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 2 warnings (0.00 sec)

Đây là một ví dụ đơn giản về ICP và cách biểu đồ này có thể mang lại lợi ích cho DBA.

Nội dung nhóm đệm InnoDB

Khi làm việc với MySQL và sử dụng công cụ InnoDB, biểu đồ này là một trong những giá trị phổ biến nhất (innodb_buffer_pool *) mà bạn phải điều chỉnh để tối ưu hóa hiệu suất của MySQL. Nói cụ thể về nội dung vùng đệm của nó, nó hiển thị xu hướng của các trang bẩn so với tổng nội dung vùng đệm. Tổng nội dung vùng đệm bao gồm các trang sạch bên cạnh các trang bẩn. Xác định mức độ hiệu quả của MySQL của bạn đang xử lý vùng đệm, biểu đồ này phục vụ mục đích của nó.
Các trang nhóm đệm InnoDB

Biểu đồ này hữu ích khi bạn muốn kiểm tra xem MySQL đang sử dụng vùng đệm InnoDB hiệu quả như thế nào. Bạn có thể sử dụng biểu đồ này, ví dụ:nếu lưu lượng truy cập hàng ngày của bạn không lấp đầy innodb_buffer_pool_size được chỉ định, thì điều này có thể chỉ ra rằng một số phần của ứng dụng không hữu ích hoặc không phục vụ bất kỳ mục đích nào hoặc nếu bạn đặt innodb_buffer_pool_size rất cao điều này có thể tốt để giảm giá trị và lấy lại dung lượng cho bộ nhớ của bạn.
Nhóm I / O bộ đệm InnoDB

Khi bạn phải kiểm tra số lượng trang được tạo và ghi trên bảng InnoDB hoặc số lần đọc trang vào vùng đệm InnoDB bằng các thao tác trên bảng InnoDB.
Yêu cầu nhóm đệm InnoDB

Khi bạn muốn xác định mức độ hiệu quả của các truy vấn của mình đang truy cập vùng đệm InnoDB, biểu đồ này phục vụ mục đích này. Biểu đồ này sẽ hiển thị các xu hướng dựa trên các điểm dữ liệu về cách máy chủ MySQL của bạn hoạt động khi công cụ InnoDB phải thường xuyên truy cập vào đĩa (chỉ báo vùng đệm chưa nóng lên), tần suất các yêu cầu vùng đệm xử lý các yêu cầu đọc và ghi yêu cầu.
InnoDB Read-Ahead

Khi bạn đã đặt biến innodb_random_read_ahead thành BẬT, thì hãy thêm biểu đồ này làm xu hướng có giá trị để xem xét như một phần của quy trình DBA của bạn. Nó cho thấy các xu hướng về cách công cụ lưu trữ MySQL InnoDB của bạn quản lý vùng đệm bằng luồng nền đọc trước, cách nó quản lý những thứ bị loại bỏ sau đó mà không bị truy cập bởi các truy vấn và cách InnoDB bắt đầu đọc trước ngẫu nhiên khi truy vấn quét một phần lớn của bảng nhưng theo thứ tự ngẫu nhiên.
Bộ đệm thay đổi InnoDB

Khi bạn đang chạy Percona Server 5.7, biểu đồ này hữu ích khi theo dõi InnoDB đã phân bổ bộ đệm thay đổi tốt như thế nào. Những thay đổi này bao gồm những lần chèn, cập nhật và xóa được chỉ định bởi biến innodb_change_buffering. Thay đổi bộ đệm giúp tăng tốc truy vấn, tránh I / O truy cập ngẫu nhiên đáng kể sẽ được yêu cầu để đọc các trang chỉ mục phụ từ đĩa.
Hoạt động bộ đệm thay đổi InnoDB

Điều này có liên quan đến biểu đồ Bộ đệm thay đổi InnoDB, nhưng phân chia thông tin thành các điểm dữ liệu khả thi hơn. Những điều này cung cấp thêm thông tin để theo dõi cách InnoDB xử lý bộ đệm thay đổi. Điều này hữu ích trong một tác vụ DBA cụ thể để xác định xem innodb_change_buffer_max_size của bạn có được đặt thành giá trị quá cao hay không, vì bộ đệm thay đổi chia sẻ cùng một bộ nhớ của vùng đệm InnoDB làm giảm bộ nhớ có sẵn cho các trang dữ liệu bộ đệm. Bạn có thể phải xem xét để vô hiệu hóa bộ đệm thay đổi nếu bộ làm việc gần như phù hợp với vùng đệm hoặc nếu bảng của bạn có tương đối ít chỉ mục phụ. Hãy nhớ rằng vùng đệm thay đổi không áp đặt thêm chi phí, vì nó chỉ áp dụng cho các trang không nằm trong vùng đệm. Biểu đồ này cũng hữu ích nếu bạn phải xác định cách hợp nhất hữu ích như thế nào nếu bạn phải đánh giá ứng dụng của mình dựa trên các yêu cầu nhất định cho các tình huống cụ thể. Giả sử bạn có chèn hàng loạt, bạn phải đặt innodb_change_buffering =insert và xác định xem việc đặt các giá trị trong vùng đệm của bạn và innodb_change_buffer_max_size không ảnh hưởng đến I / O của đĩa, đặc biệt là trong quá trình khôi phục hoặc tắt máy chậm (cần thiết nếu bạn muốn chuyển đổi dự phòng với yêu cầu thời gian chết thấp). Ngoài ra, biểu đồ này có thể phục vụ mục đích của bạn để đánh giá các tình huống nhất định, vì việc hợp nhất vùng đệm thay đổi có thể mất vài giờ khi có nhiều chỉ mục phụ cần cập nhật và nhiều hàng bị ảnh hưởng. Trong thời gian này, I / O ổ đĩa được tăng lên, có thể gây ra sự chậm lại đáng kể cho các truy vấn giới hạn ổ đĩa.

Lược đồ hiệu suất MySQL

Lược đồ Hiệu suất MySQL là một chủ đề phức tạp. Đây là một câu hỏi dài và khó, nhưng tôi sẽ chỉ thảo luận về thông tin cụ thể cho các biểu đồ mà chúng tôi có trong SCUMM. Cũng có một số biến nhất định mà bạn phải xem xét và đảm bảo chúng được đặt đúng cách. Đảm bảo rằng bạn có biến innodb_monitor_enable =all và userstat =1 để xem các điểm dữ liệu trong đồ thị của bạn. Xin lưu ý, khi tôi sử dụng từ “sự kiện” ở đây, điều đó không có nghĩa là điều này liên quan đến MySQL Event Scheduler. Tôi đang nói về các sự kiện cụ thể như MySQL phân tích cú pháp một truy vấn, MySQL đang đọc hoặc ghi vào tệp nhật ký chuyển tiếp / nhị phân, v.v.

Sau đó, hãy tiếp tục với các biểu đồ.

IO tệp giản đồ hiệu suất (Sự kiện)

Biểu đồ này tìm nạp các điểm dữ liệu liên quan đến bất kỳ sự kiện nào đã xảy ra trong MySQL mà có thể đã được thiết bị để tạo ra nhiều phiên bản của đối tượng được thiết kế (ví dụ:đọc nhật ký nhị phân hoặc đọc tệp dữ liệu InnoDB). Mỗi hàng tóm tắt các sự kiện cho một tên sự kiện nhất định. Ví dụ:nếu có một công cụ cho mutex được tạo cho mỗi kết nối, thì có thể có nhiều trường hợp của sự kiện công cụ này vì có nhiều kết nối. Hàng tóm tắt cho công cụ tóm tắt tất cả các trường hợp này. Bạn có thể kiểm tra các sự kiện này trong hướng dẫn sử dụng MySQL cho Bảng tóm tắt lược đồ hiệu suất để biết thêm thông tin.
IO tệp giản đồ hiệu suất (Tải)

Biểu đồ này giống như biểu đồ “IO của tệp giản đồ hiệu suất (Sự kiện)” ngoại trừ việc nó được thiết kế dựa trên tải.
IO tệp giản đồ hiệu suất (byte)

Biểu đồ này giống như biểu đồ “IO của tệp giản đồ hiệu suất (Sự kiện)” ngoại trừ việc nó được thiết kế dựa trên kích thước tính bằng byte. Ví dụ:một sự kiện cụ thể đã mất bao nhiêu thời gian khi MySQL kích hoạt sự kiện wait / io / file / innodb / innodb_data_file.
Thời gian chờ của giản đồ hiệu suất (Sự kiện)

Biểu đồ này có biểu đồ dữ liệu cho tất cả các lần đợi dành cho một sự kiện cụ thể. Bạn có thể kiểm tra các Bảng Tóm tắt Sự kiện Chờ trong sách hướng dẫn để biết thêm thông tin.
Thời gian chờ của giản đồ hiệu suất (Tải)

Tương tự như biểu đồ “Thời gian chờ của giản đồ hiệu suất (Sự kiện)” nhưng lần này nó hiển thị xu hướng tải.
Thao tác truy cập chỉ mục (Tải)

Biểu đồ này là tổng hợp của tất cả các sự kiện đợi I / O của chỉ mục bảng được nhóm theo (các) chỉ mục của bảng, như được tạo bởi công cụ xử lý wait / io / table / sql /. Bạn có thể xem hướng dẫn sử dụng MySQL về bảng Biểu đồ hiệu suất table_io_waits_summary_by_index_usage để biết thêm thông tin.
Thao tác truy cập bảng (Tải)

Biểu đồ “Giống như Hoạt động truy cập chỉ mục (Tải)”, nó là tổng hợp của tất cả các sự kiện chờ I / O của bảng được nhóm theo bảng, như được tạo bởi công cụ wait / io / table / sql / handler. Điều này rất hữu ích đối với DBA. Ví dụ:bạn muốn theo dõi tốc độ truy cập (tìm nạp) hoặc cập nhật (chèn, xóa, cập nhật) một bảng cụ thể. Bạn có thể kiểm tra hướng dẫn sử dụng MySQL về bảng Biểu đồ hiệu suất table_io_waits_summary_by_table để biết thêm thông tin.
Lược đồ hiệu suất SQL &Khóa bên ngoài (Sự kiện)

Biểu đồ này là tổng hợp (đếm số lần nó xảy ra) của tất cả các sự kiện chờ khóa bảng, được tạo bởi công cụ chờ / khóa / bảng / sql / xử lý được nhóm theo bảng. Khóa SQL ở đây trong biểu đồ có nghĩa là các khóa bên trong. Các khóa bên trong này được đọc bình thường, đọc với các khóa chia sẻ, đọc ưu tiên cao, đọc không chèn, ghi cho phép ghi, ghi chèn đồng thời, ghi trễ, ghi mức ưu tiên thấp, ghi bình thường. Trong khi các ổ khóa bên ngoài được đọc bên ngoài và ghi bên ngoài. Trong bất kỳ tác vụ DBA nào, điều này rất hữu ích nếu bạn phải theo dõi và điều tra các ổ khóa trên một bảng cụ thể bất kể loại của nó là gì. Bạn có thể kiểm tra bảng table_lock_waits_summary_by_table để biết thêm thông tin.
SQL giản đồ hiệu suất và các khóa bên ngoài (Giây)

Giống như biểu đồ “SQL giản đồ hiệu suất &Khóa bên ngoài (Sự kiện)”, nhưng được chỉ định trong vài giây. Nếu bạn muốn tìm kiếm các ổ khóa bảng của mình dựa trên số giây nó giữ ổ khóa, thì biểu đồ này là nguồn tốt cho bạn.

Kết luận

Số liệu InnoDB và Lược đồ Hiệu suất MySQL là một số phần chuyên sâu và phức tạp nhất trong miền MySQL, đặc biệt khi không có hình ảnh trực quan để hỗ trợ việc diễn giải. Do đó, việc truy tìm dấu vết thủ công và điều tra có thể mất một chút thời gian và công sức của bạn. Bảng điều khiển SCUMM cung cấp một cách rất hiệu quả và khả thi để xử lý những điều này và giảm tải thêm cho bất kỳ tác vụ thường xuyên DBA nào.

Trong blog này, bạn đã học cách sử dụng trang tổng quan cho InnoDB và Lược đồ hiệu suất để cải thiện hiệu suất cơ sở dữ liệu. Các trang tổng quan này có thể giúp bạn phân tích hiệu suất hiệu quả hơn.