Điều tra đỉnh cao trong thông lượng của MySQL

Gần đây một trong những máy chủ của chúng tôi đã hết bộ nhớ và bị sập. Sau khi xem xét các muninbiểu đồ, có vẻ như số liệu duy nhất (không phải là sử dụng bộ nhớ) đã đạt đến đỉnh điểm ngay trước khi sự cố là MySQL throughput. Tuy nhiên, chúng tôi đã hy vọng sẽ thấy sự gia tăng tương ứng về số lượng MySQL queriesđã không xảy ra:

Chúng tôi muốn tìm hiểu điều gì đã gây ra đỉnh cao này trong thông lượng của MySQL. Dưới đây là danh sách các bản ghi bin từ vụ tai nạn:

101M Apr 17 01:27 drupal_master-bin.001270
106M Apr 17 03:00 drupal_master-bin.001271
101M Apr 17 04:05 drupal_master-bin.001272
104M Apr 17 05:53 drupal_master-bin.001273
104M Apr 17 06:39 drupal_master-bin.001274
101M Apr 17 07:02 drupal_master-bin.001275
104M Apr 17 07:22 drupal_master-bin.001276  # 100M filled up in 1 min
106M Apr 17 07:23 drupal_master-bin.001277
101M Apr 17 07:33 drupal_master-bin.001278
101M Apr 17 07:43 drupal_master-bin.001279
104M Apr 17 07:46 drupal_master-bin.001280
102M Apr 17 08:29 drupal_master-bin.001281
102M Apr 17 08:46 drupal_master-bin.001282
105M Apr 17 08:54 drupal_master-bin.001283
 13M Apr 17 09:26 drupal_master-bin.001284  # crash of server around 09:50
# prior to crashing load went very high (we saw 45) and server was extremely slow (few min delay when typing in an SSH session)
101M Apr 17 10:54 drupal_master-bin.001285  # server up again, nothing wrong since then

Tôi đã tìm kiếm các công cụ để phân tích các bản ghi bin đó. Cho đến nay tôi đã tìm thấy:

binlog-analyze.pl : mang lại cho tôi một cái nhìn tổng quan của các truy vấn xử lý, với sự cố trên select, insert, update.. (FYI tôi thay thế select intovới selecttrong kịch bản vì nó có vẻ sai).

$ mysqlbinlog /path/to/bin.log | binlog-analyze.pl -v

pt-query-digest : cung cấp cho tôi số liệu thống kê về kích thước truy vấn (min, max, avg ...). Tiện ích đó có nhiều tùy chọn nhưng tôi không biết phải tìm gì.

$ mysqlbinlog /path/to/bin.log | pt-query-digest

Những gì chúng tôi muốn tìm hiểu là những truy vấn nào tạo ra sự gia tăng sản lượng MySQL.

Ai đó có thể đưa ra hướng dẫn về cách xem xét nhật ký bin của MySQL để xác định các truy vấn tạo ra sự gia tăng đột ngột về thông lượng của MySQL không?

Các binlog Anaylzing có thể không cung cấp cho bạn một hình ảnh chính xác vì các binlog chứa các truy vấn đã được hoàn thành và được chèn vào nhật ký nhị phân như một hàng đợi FIFO.

Những gì bạn thực sự cần tìm là lịch sử của các truy vấn đang chạy tích cực trông như thế nào. Nói cách khác, bạn cần nắm bắt danh sách quy trình trong hành động tiết lộ các truy vấn và hiệu suất như thế nào khi các trường hợp duy nhất xuất hiện.

Tôi rất khuyên bạn nên sử dụng pt-query-digest nhưng bạn cần sử dụng itt khác nhau. Ngay lập tức có quá trình phân loại truy vấn các mục binlog, hãy xử lý danh sách quy trình TRỰC TIẾP !!!

Tôi đã viết một bài đăng trước đây (ngày 24 tháng 11 năm 2011) về cách sử dụng pt-query-digest (Bài đăng của tôi sử dụng mk-query-digest ) để thay thế cho nhật ký truy vấn chậm (Tôi đã đăng tập lệnh thực tế tôi đã sử dụng cộng với cách để đọc đầu ra digest truy vấn): Hiệu ứng hiệu suất nhật ký truy vấn chung của MySQL . Bài đăng trước đây của tôi được dựa trên Video YouTube cho biết cách thực hiện . Tôi chỉ đơn giản là giả lập bản thân bằng cách sử dụng mk-query-digest .

Gần đây một trong những máy chủ của chúng tôi đã hết bộ nhớ và bị sập.

Bạn đã không cho phép trao đổi? Nếu không, MySQL sẽ chậm lại (một cách thảm hại), nhưng không sụp đổ. Trao đổi nên tránh, nhưng không được ngăn chặn.

Bạn có một số điều chỉnh thiết lập quá cao? Xem http://mysql.rjweb.org/doc.php/memory