Giám sát Máy chủ Percona cho MySQL

Trong bài đăng trên blog này, chúng ta sẽ xem xét một số chỉ số và trạng thái chính khi theo dõi Máy chủ Percona cho MySQL để giúp chúng ta tinh chỉnh cấu hình máy chủ MySQL trong thời gian dài. Xin lưu ý rằng Percona Server có một số chỉ số giám sát chỉ có sẵn trên bản dựng này. Khi so sánh trên phiên bản 8.0.20, 51 trạng thái sau chỉ khả dụng trên Máy chủ Percona dành cho MySQL, không có sẵn trong Máy chủ cộng đồng MySQL của Oracle ngược dòng:

Binlog_snapshot_file
Binlog_snapshot_position
Binlog_snapshot_gtid_executed
Com_create_compression_dictionary
Com_drop_compression_dictionary
Com_lock_tables_for_backup
Com_show_client_stosystem
Com_show_index_stosystem
Com_show_table_stosystem
Com_show_thread_stosystem
Com_show_user_stosystem
Innodb_background_log_sync
Innodb_buffer_pool_pages_LRU_flushed
Innodb_buffer_pool_pages_made_not_young
Innodb_buffer_pool_pages_made_young
Innodb_buffer_pool_pages_old
Innodb_checkpoint_age
Innodb_ibuf_free_list
Innodb_ibuf_segment_size
Innodb_lsn_current
Innodb_lsn_flushed
Innodb_lsn_last_checkpoint
Innodb_master_thread_active_loops
Innodb_master_thread_idle_loops
Innodb_max_trx_id
Innodb_oldest_view_low_limit_trx_id
Innodb_pages0_read
Innodb_purge_trx_id
Innodb_purge_undo_no
Innodb_secondary_index_triggered_cluster_reads
Innodb_secondary_index_triggered_cluster_reads_avoided
Innodb_buffered_aio_submission
Innodb_scan_pages_contiguous
Innodb_scan_pages_disjointed
Innodb_scan_pages_total_seek_distance
Innodb_scan_data_size
Innodb_scan_deleted_recs_size
Innodb_scrub_log
Innodb_scrub_background_page_reorganizations
Innodb_scrub_background_page_splits
Innodb_scrub_background_page_split_failures_underflow
Innodb_scrub_background_page_split_failures_out_of_filespace
Innodb_scrub_background_page_split_failures_missing_index
Innodb_scrub_background_page_split_failures_unknown
Innodb_encryption_n_merge_blocks_encrypted
Innodb_encryption_n_merge_blocks_decrypted
Innodb_encryption_n_rowlog_blocks_encrypted
Innodb_encryption_n_rowlog_blocks_decrypted
Innodb_encryption_redo_key_version
Threadpool_idle_threads
Threadpool_threads

Xem trang Trạng thái InnoDB Mở rộng để biết thêm thông tin về từng chỉ số giám sát ở trên. Lưu ý rằng một số trạng thái bổ sung như nhóm luồng chỉ có sẵn trong MySQL Enterprise của Oracle. Kiểm tra tài liệu Percona Server cho MySQL 8.0 để xem tất cả các cải tiến dành riêng cho bản dựng này so với MySQL Community Server 8.0 của Oracle.

Để truy xuất trạng thái toàn cục của MySQL, chỉ cần sử dụng một trong các câu lệnh sau:

mysql> SHOW GLOBAL STATUS;
mysql> SHOW GLOBAL STATUS LIKE '%connect%'; -- list all status that contain string "connect"
mysql> SELECT * FROM performance_schema.global_status;
mysql> SELECT * FROM performance_schema.global_status WHERE VARIABLE_NAME LIKE '%connect%'; -- list all status that contain string "connect"

Tổng quan và Trạng thái Cơ sở dữ liệu

Chúng ta sẽ bắt đầu với trạng thái thời gian hoạt động, số giây mà máy chủ đã hoạt động.

Tất cả trạng thái com_ * là các biến đếm câu lệnh cho biết số lần mỗi câu lệnh đã được thực thi. Có một biến trạng thái cho mỗi loại câu lệnh. Ví dụ:com_delete và com_update đếm các câu lệnh DELETE và UPDATE tương ứng. Com_delete_multi và com_update_multi tương tự nhưng áp dụng cho các câu lệnh DELETE và UPDATE sử dụng cú pháp nhiều bảng.

Để liệt kê tất cả quá trình đang chạy của MySQL, chỉ cần chạy một trong các câu lệnh sau:

mysql> SHOW PROCESSLIST;
mysql> SHOW FULL PROCESSLIST;
mysql> SELECT * FROM information_schema.processlist;
mysql> SELECT * FROM information_schema.processlist WHERE command <> 'sleep'; -- list all active processes except 'sleep' command.

Kết nối và Chủ đề

Kết nối Hiện tại

Tỷ lệ các kết nối hiện đang mở (luồng kết nối). Nếu tỷ lệ này cao, điều đó cho thấy có nhiều kết nối đồng thời đến máy chủ MySQL và có thể dẫn đến lỗi "Quá nhiều kết nối". Để nhận phần trăm kết nối:

Current connections(%) = (threads_connected / max_connections) x 100

Giá trị tốt phải từ 80% trở xuống. Hãy thử tăng biến max_connections hoặc kiểm tra các kết nối bằng SHOW FULL PROCESSLIST. Khi xảy ra lỗi "Quá nhiều kết nối", máy chủ cơ sở dữ liệu MySQL sẽ không khả dụng cho người dùng không phải là siêu người dùng cho đến khi một số kết nối được giải phóng. Lưu ý rằng việc tăng biến max_connections cũng có thể làm tăng dung lượng bộ nhớ của MySQL.

Kết nối tối đa từng thấy

Tỷ lệ kết nối tối đa đến máy chủ MySQL từng được thấy. Một phép tính đơn giản sẽ là:

Max connections ever seen(%) = (max_used_connections / max_connections) x 100

Giá trị tốt phải dưới 80%. Nếu tỷ lệ này cao, điều đó cho thấy MySQL đã từng đạt đến số lượng kết nối cao dẫn đến lỗi "quá nhiều kết nối". Kiểm tra tỷ lệ kết nối hiện tại để xem liệu nó có thực sự ở mức thấp nhất quán hay không. Nếu không, hãy tăng biến max_connections. Kiểm tra trạng thái max_used_connections_time để cho biết khi nào trạng thái max_used_connections đạt đến giá trị hiện tại.

Tỷ lệ Truy cập Bộ nhớ Cache Chủ đề

Trạng thái của thread_create là số lượng các thread được tạo ra để xử lý các kết nối. Nếu thread_create lớn, bạn có thể muốn tăng giá trị thread_cache_size. Tỷ lệ truy cập / bỏ lỡ bộ nhớ cache có thể được tính như sau:

Threads cache hit rate (%) = (threads_created / connections) x 100

Đây là một phần nhỏ cho biết tỷ lệ truy cập bộ nhớ đệm luồng. Càng gần dưới 50% càng tốt. Nếu máy chủ của bạn thấy hàng trăm kết nối mỗi giây, bạn thường nên đặt thread_cache_size đủ cao để hầu hết các kết nối mới sử dụng các chuỗi được lưu trong bộ nhớ cache.

Hiệu suất Truy vấn

Quét Toàn Bảng

Tỷ lệ quét toàn bộ bảng, một thao tác yêu cầu đọc toàn bộ nội dung của bảng, thay vì chỉ các phần được chọn bằng cách sử dụng chỉ mục. Giá trị này cao nếu bạn đang thực hiện nhiều truy vấn yêu cầu sắp xếp kết quả hoặc quét bảng. Nói chung, điều này cho thấy rằng các bảng không được lập chỉ mục đúng cách hoặc các truy vấn của bạn không được viết để tận dụng các chỉ mục bạn có. Để tính toán phần trăm quét toàn bộ bảng:

Full table scans (%) = (handler_read_rnd_next + handler_read_rnd) / 
(handler_read_rnd_next + handler_read_rnd + handler_read_first + handler_read_next + handler_read_key + handler_read_prev) 
x 100

Giá trị tốt phải dưới 25%. Kiểm tra đầu ra nhật ký truy vấn chậm MySQL để tìm ra các truy vấn không tối ưu.

Chọn Tham gia Toàn bộ

Trạng thái của select_full_join là số liên kết thực hiện quét bảng vì chúng không sử dụng chỉ mục. Nếu giá trị này không phải là 0, bạn nên kiểm tra cẩn thận các chỉ mục của bảng.

Chọn Kiểm tra Phạm vi

Trạng thái của select_range_check là số lượng liên kết không có khóa kiểm tra việc sử dụng khóa sau mỗi hàng. Nếu đây không phải là 0, bạn nên kiểm tra cẩn thận các chỉ mục của bảng của mình.

Sắp xếp Thẻ

Tỷ lệ giữa các lần hợp nhất mà thuật toán sắp xếp đã phải thực hiện. Nếu giá trị này cao, bạn nên cân nhắc việc tăng giá trị của sort_buffer_size và read_rnd_buffer_size. Một phép tính tỷ lệ đơn giản là:

Sort passes = sort_merge_passes / (sort_scan + sort_range)

Giá trị tỷ lệ thấp hơn 3 phải là một giá trị tốt. Nếu bạn muốn tăng sort_buffer_size hoặc read_rnd_buffer_size, hãy cố gắng tăng theo từng bước nhỏ cho đến khi bạn đạt đến tỷ lệ có thể chấp nhận được.

Hiệu suất InnoDB

Tỷ lệ truy cập nhóm bộ đệm InnoDB

Tỷ lệ tần suất các trang của bạn được truy xuất từ bộ nhớ thay vì đĩa. Nếu giá trị thấp trong thời gian đầu khởi động MySQL, vui lòng chờ một chút thời gian để vùng đệm ấm lên. Để có được tỷ lệ truy cập vùng đệm, hãy sử dụng câu lệnh SHOW ENGINE INNODB STATUS:

mysql> SHOW ENGINE INNODB STATUS\G
...
----------------------
BUFFER POOL AND MEMORY
----------------------
...
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
...

Giá trị tốt nhất là 1000/10000 tỷ lệ truy cập. Ví dụ:đối với một giá trị thấp hơn, tỷ lệ truy cập 986/1000 cho biết rằng trong số 1000 lần đọc trang, nó có thể đọc các trang trong RAM 986 lần. 14 lần còn lại, MySQL phải đọc các trang từ đĩa. Nói một cách đơn giản, 1000/1000 là giá trị tốt nhất mà chúng tôi đang cố gắng đạt được ở đây, có nghĩa là dữ liệu được truy cập thường xuyên nằm gọn trong RAM.

Việc tăng biến innodb_buffer_pool_size sẽ giúp ích rất nhiều để có thêm không gian cho MySQL hoạt động. Tuy nhiên, hãy đảm bảo bạn có đủ tài nguyên RAM trước đó. Loại bỏ các chỉ mục thừa cũng có thể hữu ích. Nếu bạn có nhiều phiên bản vùng đệm, hãy đảm bảo tỷ lệ truy cập cho mỗi phiên bản đạt 1000 / 1000.

Trang Bẩn của InnoDB

Tỷ lệ tần suất InnoDB cần được xả. Trong quá trình tải nặng ghi, tỷ lệ phần trăm này tăng lên là điều bình thường.

Một phép tính đơn giản sẽ là:

InnoDB dirty pages(%) = (innodb_buffer_pool_pages_dirty / innodb_buffer_pool_pages_total) x 100

Giá trị tốt phải từ 75% trở xuống. Nếu tỷ lệ trang bẩn vẫn cao trong một thời gian dài, bạn có thể muốn tăng vùng đệm hoặc tải các đĩa nhanh hơn để tránh tắc nghẽn hiệu suất.

InnoDB Chờ cho Trạm kiểm soát

Tỷ lệ tần suất InnoDB cần đọc hoặc tạo một trang mà không có trang sạch nào có sẵn. Thông thường, việc ghi vào Nhóm đệm InnoDB xảy ra ở chế độ nền. Tuy nhiên, nếu cần đọc hoặc tạo một trang và không có trang sạch nào, thì cũng cần phải đợi các trang được xả trước. Bộ đếm innodb_buffer_pool_wait_free đếm số lần điều này đã xảy ra. Để tính toán tỷ lệ InnoDB chờ điểm kiểm tra, chúng ta có thể sử dụng phép tính sau:

InnoDB waits for checkpoint = innodb_buffer_pool_wait_free / innodb_buffer_pool_write_requests

Nếu innodb_buffer_pool_wait_free lớn hơn 0, thì đó là một dấu hiệu mạnh cho thấy vùng đệm InnoDB quá nhỏ và các hoạt động phải chờ ở một điểm kiểm tra. Việc tăng innodb_buffer_pool_size thường sẽ làm giảm innodb_buffer_pool_wait_free, cũng như tỷ lệ này. Giá trị tỷ lệ tốt phải ở dưới mức 1.

InnoDB Chờ Redolog

Tỷ lệ tranh chấp nhật ký làm lại. Kiểm tra innodb_log_waits và nếu nó tiếp tục tăng thì hãy tăng innodb_log_buffer_size. Nó cũng có thể có nghĩa là đĩa quá chậm và không thể duy trì IO đĩa, có lẽ do tải ghi cao điểm. Sử dụng phép tính sau để tính toán tỷ lệ chờ nhật ký làm lại:

InnoDB waits for redolog = innodb_log_waits / innodb_log_writes

Giá trị tỷ lệ tốt phải dưới 1. Nếu không, hãy tăng innodb_log_buffer_size.

Bảng

Sử dụng Bộ nhớ đệm Bảng

Tỷ lệ sử dụng bộ nhớ cache của bảng cho tất cả các luồng. Một phép tính đơn giản sẽ là:

Table cache usage(%) = (opened_tables / table_open_cache) x 100

Giá trị tốt phải nhỏ hơn 80%. Tăng biến table_open_cache cho đến khi phần trăm đạt giá trị tốt.

Tỷ lệ truy cập vào bộ nhớ đệm của bảng

Tỷ lệ sử dụng lần truy cập bộ nhớ cache của bảng. Một phép tính đơn giản sẽ là:

Table cache hit ratio(%) = (open_tables / opened_tables) x 100

Giá trị tỷ lệ truy cập tốt phải từ 90% trở lên. Nếu không, hãy tăng biến table_open_cache cho đến khi tỷ lệ truy cập đạt giá trị tốt.

Giám sát số liệu với ClusterControl

ClusterControl hỗ trợ Percona Server cho MySQL và nó cung cấp một cái nhìn tổng hợp của tất cả các nút trong một cụm trong trang ClusterControl -> Performance -> DB Status. Điều này cung cấp một cách tiếp cận tập trung để tìm kiếm tất cả trạng thái trên tất cả các máy chủ với khả năng lọc trạng thái, như thể hiện trong ảnh chụp màn hình sau:

Để truy xuất đầu ra SHOW ENGINE INNODB STATUS cho từng máy chủ, bạn có thể sử dụng trang Hiệu suất -> Trạng thái InnoDB, như được hiển thị bên dưới:

ClusterControl cũng cung cấp các cố vấn tích hợp mà bạn có thể sử dụng để theo dõi cơ sở dữ liệu của mình màn biểu diễn. Tính năng này có thể truy cập được trong ClusterControl -> Performance -> Advisors:

Advisors về cơ bản là các chương trình nhỏ được thực thi bởi ClusterControl trong một thời gian đã lên lịch như cron việc làm. Bạn có thể lên lịch cố vấn bằng cách nhấp vào nút "Cố vấn lập lịch" và chọn bất kỳ cố vấn hiện có nào từ cây đối tượng Developer Studio:

Nhấp vào nút "Cố vấn lịch biểu" để đặt lập lịch, đối số thành vượt qua và cả thẻ của cố vấn. Bạn cũng có thể biên dịch cố vấn để xem đầu ra ngay lập tức bằng cách nhấp vào nút "Biên dịch và chạy", nơi bạn sẽ thấy kết quả sau trong "Thông báo" bên dưới nó:

Bạn có thể tạo cố vấn của riêng mình bằng cách tham khảo Hướng dẫn dành cho nhà phát triển này, được viết bằng Ngôn ngữ cụ thể của miền ClusterControl (rất giống với Javascript) hoặc tùy chỉnh một cố vấn hiện có cho phù hợp với chính sách giám sát của bạn. Tóm lại, nhiệm vụ giám sát ClusterControl có thể được mở rộng với khả năng không giới hạn thông qua ClusterControl Advisors.