Tôi đang gặp phải tình trạng sử dụng CPU cao trên Amazon Relational Database Service [Amazon RDS] cho các phiên bản Cơ sở dữ liệu MySQL hoặc các phiên bản Amazon Aurora Phiên bản tương thích với MySQL của tôi. Làm cách nào tôi có thể khắc phục sự cố và giải quyết tình trạng sử dụng CPU cao?
Mô tả ngắn
Việc tăng hiệu suất sử dụng CPU có thể do một số yếu tố gây ra, chẳng hạn như khối lượng công việc nặng do người dùng thực hiện, nhiều truy vấn đồng thời hoặc các giao dịch chạy trong thời gian dài
Để xác định nguồn sử dụng CPU trong phiên bản Amazon RDS for MySQL của bạn, hãy xem xét các phương pháp sau
- Tăng cường giám sát
- Thông tin chi tiết về hiệu suất
- Các truy vấn phát hiện nguyên nhân sử dụng CPU trong khối lượng công việc
- Nhật ký với giám sát được kích hoạt
Sau khi bạn xác định nguồn, bạn có thể phân tích và tối ưu hóa khối lượng công việc của mình để giảm mức sử dụng CPU
Nghị quyết
Sử dụng giám sát nâng cao
Giám sát nâng cao cung cấp chế độ xem ở cấp hệ điều hành [OS]. Chế độ xem này có thể giúp xác định nguyên nhân tải CPU cao ở cấp độ chi tiết. Ví dụ: bạn có thể xem lại mức trung bình tải, phân phối CPU [% hệ thống hoặc tốt đẹp%] và danh sách quy trình HĐH
Sử dụng Giám sát nâng cao, bạn có thể kiểm tra dữ liệu loadAverageMinute trong khoảng thời gian 1, 5 và 15 phút. Mức tải trung bình lớn hơn số lượng vCPU cho biết rằng phiên bản đang chịu tải nặng. Ngoài ra, nếu mức tải trung bình ít hơn số lượng vCPU cho lớp phiên bản CSDL, thì việc tiết chế CPU có thể không phải là nguyên nhân gây ra độ trễ của ứng dụng. Kiểm tra tải trung bình để tránh dương tính giả khi chẩn đoán nguyên nhân sử dụng CPU
Ví dụ: nếu bạn có một phiên bản CSDL đang sử dụng một db. m5. 2xlarge với 3000 IOPS được cung cấp đạt đến giới hạn CPU, bạn có thể xem lại các chỉ số ví dụ sau để xác định nguyên nhân gốc rễ của việc sử dụng CPU cao. Trong ví dụ sau, lớp phiên bản có tám vCPU được liên kết với nó. Đối với cùng mức tải trung bình, vượt quá 170 cho biết máy đang chịu tải nặng trong khung thời gian đo được
Tải phút trung bình
Ghi chú. Amazon RDS cung cấp cho khối lượng công việc của bạn mức độ ưu tiên cao hơn so với các tác vụ khác đang chạy trên phiên bản CSDL. Để ưu tiên các tác vụ này, các tác vụ khối lượng công việc có giá trị Nice cao hơn. Do đó, trong Giám sát nâng cao, Nice% biểu thị lượng CPU được sử dụng bởi khối lượng công việc của bạn đối với cơ sở dữ liệu
Sau khi bật Giám sát nâng cao, bạn cũng có thể kiểm tra danh sách quy trình HĐH được liên kết với phiên bản CSDL. Giám sát nâng cao hiển thị tối đa 100 quy trình. Điều này có thể giúp bạn xác định quy trình nào có tác động lớn nhất đến hiệu suất dựa trên việc sử dụng CPU và bộ nhớ
Trong phần danh sách quy trình hệ điều hành [OS] của Giám sát nâng cao, hãy xem xét các quy trình OS và quy trình RDS. Xác nhận tỷ lệ sử dụng CPU của quy trình mysqld hoặc Aurora. Các số liệu này có thể giúp bạn xác nhận xem việc tăng hiệu suất sử dụng CPU là do HĐH hay do các quy trình RDS gây ra. Hoặc, bạn có thể sử dụng các số liệu này để theo dõi mọi mức tăng sử dụng CPU do mysqld hoặc Aurora gây ra. Bạn cũng có thể xem sự phân chia mức sử dụng CPU bằng cách xem xét các chỉ số cho cpuUtilization. Để biết thêm thông tin, hãy xem Giám sát số liệu hệ điều hành với Giám sát nâng cao
Ghi chú. Nếu bạn kích hoạt Lược đồ hiệu suất, thì bạn có thể ánh xạ ID luồng hệ điều hành với ID tiến trình của cơ sở dữ liệu của bạn. Để biết thêm thông tin, hãy xem Tại sao phiên bản CSDL Amazon RDS của tôi lại sử dụng bộ nhớ hoán đổi khi tôi có đủ bộ nhớ?
Sử dụng thông tin chi tiết về hiệu suất
Sử dụng truy vấn để phát hiện nguyên nhân sử dụng CPU trong khối lượng công việc
Trước khi bạn có thể tối ưu hóa khối lượng công việc của mình, bạn phải xác định truy vấn có vấn đề. Bạn có thể chạy các truy vấn sau trong khi xảy ra sự cố CPU cao để xác định nguyên nhân gốc rễ của việc sử dụng CPU. Sau đó, tối ưu hóa khối lượng công việc của bạn để giảm mức sử dụng CPU của bạn
Lệnh SHOW PROCESSLIST hiển thị cho bạn các luồng hiện đang chạy trên phiên bản MySQL của bạn. Đôi khi, cùng một nhóm câu lệnh có thể tiếp tục chạy mà không hoàn thành. Khi điều này xảy ra, các câu lệnh tiếp theo phải đợi tập hợp các câu lệnh đầu tiên kết thúc. Điều này là do khóa cấp hàng InnoDB có thể đang cập nhật các hàng giống nhau. Để biết thêm thông tin, hãy xem câu lệnh SHOW PROCESSLIST trên trang web MySQL
Ghi chú. Chạy truy vấn SHOW PROCESSLIST với tư cách là người dùng hệ thống chính. Nếu bạn không phải là người dùng hệ thống chính, thì bạn phải có quyền quản trị máy chủ MySQL PROCESS để xem tất cả các luồng đang chạy trên phiên bản MySQL. Không có đặc quyền của quản trị viên, SHOW PROCESSLIST chỉ hiển thị các luồng được liên kết với tài khoản MySQL mà bạn đang sử dụng
Bảng INNODB_TRX cung cấp thông tin về tất cả các giao dịch InnoDB hiện đang chạy không phải là giao dịch chỉ đọc
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;Bảng INNODB_LOCKS cung cấp thông tin về các khóa mà giao dịch InnoDB đã yêu cầu nhưng chưa nhận được
Đối với MySQL 5. 7 hoặc sớm hơn
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;SELECT * FROM performance_schema.data_locks;Bảng INNODB_LOCK_WAITS cung cấp một hoặc nhiều hàng cho mỗi giao dịch InnoDB bị chặn
Đối với MySQL 5. 7 hoặc sớm hơn
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;SELECT * FROM performance_schema.data_lock_waits;Bạn có thể chạy một truy vấn tương tự như sau để xem các giao dịch đang chờ và các giao dịch đang chặn các giao dịch đang chờ. Để biết thêm thông tin, hãy xem Sử dụng thông tin khóa và giao dịch InnoDB trên trang web MySQL
Đối với MySQL 5. 7 hoặc sớm hơn
SELECT
r.trx_id waiting_trx_id,
r.trx_mysql_thread_id waiting_thread,
r.trx_query waiting_query,
b.trx_id blocking_trx_id,
b.trx_mysql_thread_id blocking_thread,
b.trx_query blocking_query
FROM information_schema.innodb_lock_waits w
INNER JOIN information_schema.innodb_trx b
ON b.trx_id = w.blocking_trx_id
INNER JOIN information_schema.innodb_trx r
ON r.trx_id = w.requesting_trx_id;SELECT
r.trx_id waiting_trx_id,
r.trx_mysql_thread_id waiting_thread,
r.trx_query waiting_query,
b.trx_id blocking_trx_id,
b.trx_mysql_thread_id blocking_thread,
b.trx_query blocking_query
FROM performance_schema.data_lock_waits w
INNER JOIN information_schema.innodb_trx b
ON b.trx_id = w.blocking_engine_transaction_id
INNER JOIN information_schema.innodb_trx r
ON r.trx_id = w.requesting_engine_transaction_id;Truy vấn SHOW ENGINE INNODB STATUS cung cấp thông tin từ màn hình InnoDB tiêu chuẩn về trạng thái của công cụ lưu trữ InnoDB. Để biết thêm thông tin, hãy xem câu lệnh SHOW ENGINE trên trang web MySQL
SHOW ENGINE INNODB STATUS;HIỂN THỊ [ TOÀN CẦU. SESSION] STATUS cung cấp thông tin về trạng thái máy chủ. Để biết thêm thông tin, hãy xem câu lệnh SHOW STATUS trên trang web MySQL
Ghi chú. Các truy vấn này đã được thử nghiệm trên Aurora 2. x [MySQL 5. 7]; . x [MySQL 5. 6]; . x. Ngoài ra, INFORMATION_SCHEMA. Bảng INNODB_LOCKS không còn được hỗ trợ kể từ MySQL 5. 7. 14 và bị xóa trong MySQL 8. 0. hiệu suất_lược đồ. bảng data_locks thay thế INFORMATION_SCHEMA. Bảng INNODB_LOCKS. Để biết thêm thông tin, hãy xem Bảng data_locks trên trang web MySQL
Phân tích nhật ký và bật giám sát
Khi bạn phân tích nhật ký hoặc muốn kích hoạt tính năng giám sát trong Amazon RDS for MySQL, hãy xem xét các phương pháp sau
- Phân tích Nhật ký truy vấn chung của MySQL để xem mysqld đang làm gì tại một thời điểm cụ thể. Bạn cũng có thể xem các truy vấn đang chạy trên phiên bản của mình tại một thời điểm cụ thể, bao gồm thông tin về thời điểm máy khách kết nối hoặc ngắt kết nối. Để biết thêm thông tin, hãy xem Nhật ký truy vấn chung trên trang web MySQL.
Lưu ý. Khi bạn kích hoạt Nhật ký truy vấn chung trong thời gian dài, nhật ký sẽ sử dụng dung lượng lưu trữ và có thể thêm vào chi phí hoạt động. - Phân tích Nhật ký truy vấn chậm của MySQL để tìm các truy vấn mất nhiều thời gian chạy hơn số giây mà bạn đặt cho long_query_time. Bạn cũng có thể xem lại khối lượng công việc và phân tích các truy vấn của mình để cải thiện hiệu suất và mức tiêu thụ bộ nhớ. Để biết thêm thông tin, hãy xem Nhật ký truy vấn chậm trên trang web MySQL. Mẹo. Khi bạn sử dụng Nhật ký truy vấn chậm hoặc Nhật ký truy vấn chung, hãy đặt tham số log_output thành FILE
- Sử dụng Plugin kiểm tra MariaDB để kiểm tra hoạt động cơ sở dữ liệu. Ví dụ: bạn có thể theo dõi người dùng đang đăng nhập vào cơ sở dữ liệu hoặc các truy vấn đang chạy trên cơ sở dữ liệu. Để biết thêm thông tin, hãy xem hỗ trợ Plugin kiểm tra MariaDB
- Nếu bạn sử dụng Aurora cho MySQL thì bạn cũng có thể sử dụng Kiểm tra nâng cao. Kiểm tra có thể cung cấp cho bạn nhiều quyền kiểm soát hơn đối với các loại truy vấn bạn muốn ghi lại. Làm như vậy sẽ giảm chi phí đăng nhập
- Sử dụng tham số innodb_print_all_deadlocks để kiểm tra các bế tắc và khóa tài nguyên. Bạn có thể sử dụng tham số này để ghi lại thông tin về các bế tắc trong giao dịch người dùng InnoDB trong nhật ký lỗi MySQL. Để biết thêm thông tin, hãy xem innodb_print_all_deadlocks trên trang web MySQL
Phân tích và tối ưu hóa khối lượng công việc CPU cao
Sau khi bạn xác định truy vấn đang làm tăng mức sử dụng CPU, hãy tối ưu hóa khối lượng công việc của bạn để giảm mức tiêu thụ CPU
Nếu bạn thấy một truy vấn không cần thiết cho khối lượng công việc của mình, bạn có thể ngắt kết nối bằng lệnh sau
________số 8
Để tìm processID của truy vấn, hãy chạy lệnh SHOW FULL PROCESSLIST
Nếu bạn không muốn kết thúc truy vấn, hãy tối ưu hóa truy vấn bằng cách sử dụng GIẢI THÍCH. Lệnh EXPLAIN hiển thị các bước riêng lẻ liên quan đến việc chạy truy vấn. Để biết thêm thông tin, hãy xem Tối ưu hóa truy vấn với GIẢI THÍCH trên trang web MySQL
Để xem lại chi tiết hồ sơ, kích hoạt PROFILING. Lệnh PROFILING có thể chỉ ra việc sử dụng tài nguyên cho các câu lệnh đang chạy trong phiên hiện tại. Để biết thêm thông tin, hãy xem câu lệnh SHOW PROFILE trên trang web MySQL
Để cập nhật bất kỳ thống kê bảng nào, hãy sử dụng ANALYZE TABLE. Lệnh ANALYZE TABLE có thể giúp trình tối ưu hóa chọn một kế hoạch thích hợp để chạy truy vấn. Để biết thêm thông tin, hãy xem câu lệnh ANALYZE TABLE trên trang web MySQL