Xử lý các truy vấn chạy dài của MySQL

Các truy vấn / câu lệnh / giao dịch chạy dài đôi khi là không thể tránh khỏi trong môi trường MySQL. Trong một số trường hợp, một truy vấn chạy dài có thể là chất xúc tác dẫn đến một sự kiện thảm khốc. Nếu bạn quan tâm đến cơ sở dữ liệu của mình, việc tối ưu hóa hiệu suất truy vấn và phát hiện các truy vấn chạy dài phải được thực hiện thường xuyên. Tuy nhiên, mọi thứ sẽ trở nên khó khăn hơn khi nhiều trường hợp trong một nhóm hoặc cụm có liên quan.

Khi xử lý nhiều nút, các tác vụ lặp đi lặp lại để kiểm tra từng nút đơn lẻ là điều mà chúng ta phải tránh. ClusterControl giám sát nhiều khía cạnh của máy chủ cơ sở dữ liệu của bạn, bao gồm cả các truy vấn. ClusterControl tổng hợp tất cả thông tin liên quan đến truy vấn từ tất cả các nút trong nhóm hoặc cụm để cung cấp chế độ xem tập trung về khối lượng công việc. Có một cách tuyệt vời để hiểu toàn bộ cụm của bạn với nỗ lực tối thiểu.

Trong bài đăng trên blog này, chúng tôi chỉ cho bạn cách phát hiện các truy vấn đang chạy dài của MySQL bằng cách sử dụng ClusterControl.

Tại sao một truy vấn lại mất nhiều thời gian hơn?

Trước hết, chúng ta phải biết bản chất của truy vấn, cho dù nó được mong đợi là một truy vấn chạy dài hay chạy ngắn. Một số hoạt động phân tích và hàng loạt được cho là các truy vấn chạy dài, vì vậy chúng ta có thể bỏ qua chúng ngay bây giờ. Ngoài ra, tùy thuộc vào kích thước bảng, việc sửa đổi cấu trúc bảng bằng lệnh ALTER có thể là một hoạt động lâu dài.

Đối với một giao dịch trong khoảng thời gian ngắn, nó phải được thực hiện càng nhanh càng tốt, thường là chỉ trong vài giây. Càng ngắn càng tốt. Điều này đi kèm với một tập hợp các quy tắc thực hành tốt nhất của truy vấn mà người dùng phải tuân theo, như sử dụng lập chỉ mục thích hợp trong câu lệnh WHERE hoặc JOIN, sử dụng công cụ lưu trữ phù hợp, chọn kiểu dữ liệu phù hợp, lập lịch hoạt động hàng loạt trong giờ thấp điểm, phân tích giảm tải / báo cáo lưu lượng truy cập đến các bản sao chuyên dụng, v.v.

Có một số điều có thể khiến truy vấn mất nhiều thời gian hơn để thực thi:

Truy vấn không hiệu quả - Sử dụng các cột không được lập chỉ mục trong khi tra cứu hoặc kết hợp, do đó MySQL mất nhiều thời gian hơn để phù hợp với điều kiện.
Khóa bảng - Bảng bị khóa, bằng khóa toàn cục hoặc khóa bảng rõ ràng khi truy vấn đang cố truy cập.
Chốt lại - Một truy vấn đang chờ truy cập vào các hàng tương tự bị khóa bởi một truy vấn khác.
Tập dữ liệu không vừa với RAM - Nếu dữ liệu tập hợp làm việc của bạn phù hợp với bộ nhớ cache đó, thì các truy vấn CHỌN thường sẽ tương đối nhanh.
Tài nguyên phần cứng không tối ưu - Đây có thể là đĩa chạy chậm, quá trình xây dựng lại RAID, mạng bão hòa, v.v.
Hoạt động bảo trì - Việc chạy mysqldump có thể đưa một lượng lớn dữ liệu chưa được sử dụng vào vùng đệm và đồng thời dữ liệu (có thể hữu ích) đã có sẵn sẽ bị loại bỏ và chuyển vào đĩa.

Danh sách trên nhấn mạnh rằng chính truy vấn không chỉ gây ra tất cả các loại vấn đề. Có rất nhiều lý do đòi hỏi phải xem xét các khía cạnh khác nhau của máy chủ MySQL. Trong một số trường hợp xấu hơn, một truy vấn chạy dài có thể gây ra gián đoạn dịch vụ hoàn toàn như máy chủ ngừng hoạt động, máy chủ gặp sự cố và kết nối tối đa. Nếu bạn thấy một truy vấn mất nhiều thời gian hơn bình thường để thực thi, hãy điều tra nó.

Làm thế nào để kiểm tra?

DANH SÁCH QUY TRÌNH

MySQL cung cấp một số công cụ tích hợp để kiểm tra giao dịch đang hoạt động lâu dài. Trước hết, các lệnh SHOW PROCESSLIST hoặc SHOW FULL PROCESSLIST có thể hiển thị các truy vấn đang chạy trong thời gian thực. Đây là ảnh chụp màn hình của tính năng ClusterControl Running Queries, tương tự như lệnh SHOW FULL PROCESSLIST (nhưng ClusterControl tổng hợp tất cả quá trình vào một chế độ xem cho tất cả các nút trong cụm):

Như bạn thấy, chúng ta có thể thấy ngay câu truy vấn gây khó chịu ngay từ đầu ra. Nhưng chúng ta thường nhìn chằm chằm vào những quá trình đó như thế nào? Điều này chỉ hữu ích nếu bạn biết về giao dịch đang diễn ra trong thời gian dài. Nếu không, bạn sẽ không biết cho đến khi có điều gì đó xảy ra - chẳng hạn như các kết nối đang chồng chất lên nhau hoặc máy chủ chạy chậm hơn bình thường.

Nhật ký truy vấn chậm

Nhật ký truy vấn chậm ghi lại các truy vấn chậm (các câu lệnh SQL mất nhiều hơn long_query_time giây để thực thi) hoặc các truy vấn không sử dụng chỉ mục để tra cứu ( log_queries_not_using_indexes ). Tính năng này không được bật theo mặc định và để bật nó chỉ cần đặt các dòng sau và khởi động lại máy chủ MySQL:

[mysqld]
slow_query_log=1
long_query_time=0.1
log_queries_not_using_indexes=1

Nhật ký truy vấn chậm có thể được sử dụng để tìm các truy vấn mất nhiều thời gian để thực thi và do đó là ứng cử viên để tối ưu hóa. Tuy nhiên, việc kiểm tra nhật ký truy vấn chậm dài có thể là một công việc tốn nhiều thời gian. Có các công cụ để phân tích cú pháp các tệp nhật ký truy vấn chậm của MySQL và tóm tắt nội dung của chúng như mysqldumpslow, pt-query-crypt hoặc ClusterControl Top Queries.

ClusterControl Top Queries tóm tắt truy vấn chậm bằng hai phương pháp - Nhật ký truy vấn chậm MySQL hoặc Lược đồ Hiệu suất:

Bạn có thể dễ dàng xem bản tóm tắt các thông báo về câu lệnh chuẩn hóa, được sắp xếp dựa trên một số tiêu chí:

Máy chủ lưu trữ
Lần xuất hiện
Tổng thời gian thực hiện
Thời gian thực hiện tối đa
Thời gian thực hiện trung bình
Thời gian lệch chuẩn

Chúng tôi đã trình bày rất chi tiết về tính năng này trong bài đăng blog này, Cách sử dụng Trình theo dõi truy vấn ClusterControl cho MySQL, MariaDB và Máy chủ Percona.

Giản đồ hiệu suất

Lược đồ hiệu suất là một công cụ tuyệt vời có sẵn để theo dõi nội bộ Máy chủ MySQL và chi tiết thực thi ở cấp độ thấp hơn. Các bảng sau trong Lược đồ hiệu suất có thể được sử dụng để tìm các truy vấn chậm:

sự kiện_statements_current
sự kiện_statements_history
sự kiện_statements_history_long
sự kiện_statements_summary_by_digest
sự kiện_statements_summary_by_user_by_event_name
sự kiện_statements_summary_by_host_by_event_name

MySQL 5.7.7 trở lên bao gồm lược đồ sys, một tập hợp các đối tượng giúp DBA và các nhà phát triển giải thích dữ liệu được thu thập bởi Lược đồ hiệu suất thành dạng dễ hiểu hơn. Các đối tượng lược đồ Sys có thể được sử dụng cho các trường hợp sử dụng điều chỉnh và chẩn đoán điển hình.

ClusterControl cung cấp các cố vấn, là các chương trình nhỏ mà bạn có thể viết bằng ClusterControl DSL (tương tự như JavaScript) để mở rộng các khả năng giám sát ClusterControl tùy chỉnh theo nhu cầu của bạn. Có một số tập lệnh được bao gồm dựa trên Lược đồ hiệu suất mà bạn có thể sử dụng để theo dõi hiệu suất truy vấn như chờ I / O, khóa thời gian chờ, v.v. Ví dụ:trong Manage -> Developer Studio , truy cập s9s -> mysql -> p_s -> top_tables_by_iowait.js và nhấp vào nút "Biên dịch và Chạy". Bạn sẽ thấy đầu ra trong tab Tin nhắn cho 10 bảng hàng đầu được sắp xếp theo thời gian chờ I / O trên mỗi máy chủ:

Có một số tập lệnh mà bạn có thể sử dụng để hiểu thông tin cấp thấp về nguyên nhân và vị trí xảy ra chậm như top_tables_by_lockwait.js , top_accessed_db_files.js và như vậy.

ClusterControl - Phát hiện và cảnh báo khi có các truy vấn chạy dài

Với ClusterControl, bạn sẽ nhận được các tính năng mạnh mẽ bổ sung mà bạn sẽ không tìm thấy trong cài đặt MySQL tiêu chuẩn. ClusterControl có thể được định cấu hình để chủ động theo dõi các quá trình đang chạy, đồng thời báo động và gửi thông báo cho người dùng nếu vượt quá ngưỡng truy vấn dài. Điều này có thể được định cấu hình bằng cách sử dụng Cấu hình thời gian chạy trong Cài đặt:

Đối với pre1.7.1, giá trị mặc định cho query_monitor_alert_long_running_query là sai. Chúng tôi khuyến khích người dùng kích hoạt điều này bằng cách đặt nó thành 1 (true). Để làm cho nó hoạt động ổn định, hãy thêm dòng sau vào /etc/cmon.d/cmon_X.cnf:

query_monitor_alert_long_running_query=1
query_monitor_long_running_query_ms=30000

Bất kỳ thay đổi nào được thực hiện trong Cấu hình thời gian chạy đều được áp dụng ngay lập tức và không cần khởi động lại. Bạn sẽ thấy thông báo như thế này trong phần Báo thức nếu truy vấn vượt quá ngưỡng 30000 mili giây (30 giây):

Nếu bạn định cấu hình cài đặt người nhận thư là "Gửi" cho danh mục mức độ nghiêm trọng của DbComponent cộng với CRITICAL (như được hiển thị trong ảnh chụp màn hình sau):

Bạn sẽ nhận được một bản sao của cảnh báo này trong email của mình. Nếu không, nó có thể được chuyển tiếp theo cách thủ công bằng cách nhấp vào nút "Gửi Email".

Hơn nữa, bạn có thể lọc ra bất kỳ loại tài nguyên danh sách xử lý nào phù hợp với các tiêu chí nhất định với biểu thức chính quy (regex). Ví dụ:nếu bạn muốn ClusterControl phát hiện truy vấn đang chạy dài cho ba người dùng MySQL được gọi là 'sbtest', 'myshop' và 'db_user1', bạn nên làm như sau:

Mọi thay đổi được thực hiện trong Cấu hình thời gian chạy sẽ được áp dụng ngay lập tức và không cần khởi động lại.

Ngoài ra, ClusterControl sẽ liệt kê tất cả các giao dịch bế tắc cùng với trạng thái InnoDB khi nó đang xảy ra trong Hiệu suất -> Nhật ký giao dịch :

Tính năng này không được bật theo mặc định, do việc phát hiện bế tắc sẽ ảnh hưởng đến việc sử dụng CPU trên các nút cơ sở dữ liệu. Để kích hoạt nó, chỉ cần đánh dấu vào hộp kiểm "Bật Nhật ký Giao dịch" và chỉ định khoảng thời gian bạn muốn. Để làm cho nó ổn định, hãy thêm biến có giá trị tính bằng giây bên trong /etc/cmon.d/cmon_X.cnf:

db_deadlock_check_interval=30

Tương tự, nếu bạn muốn kiểm tra trạng thái InnoDB, chỉ cần đi tới Hiệu suất -> Trạng thái InnoDB và chọn máy chủ MySQL từ menu thả xuống. Ví dụ:

Vậy là xong - tất cả thông tin được yêu cầu đều có thể dễ dàng truy xuất chỉ trong một vài cú nhấp chuột.

Tóm tắt

Các giao dịch đang hoạt động lâu có thể dẫn đến giảm hiệu suất, máy chủ ngừng hoạt động, kết nối tối đa và bế tắc. Với ClusterControl, bạn có thể phát hiện các truy vấn đang chạy dài trực tiếp từ giao diện người dùng mà không cần phải kiểm tra từng nút MySQL trong cụm.