Đấu tranh để gỡ lỗi sử dụng CPU cao trên phiên bản Amazon RDS MySQL

Chúng tôi đang chạy một máy chủ MySQL RDS m1.xlarge và gặp một số vấn đề với việc sử dụng CPU cao. Chúng tôi đã gặp một số vấn đề vài tuần trước với việc sử dụng CPU đạt 100% trên một ví dụ lớn. Khi chúng tôi nâng cấp kích thước lên xlarge giúp ổn định mọi thứ trong một thời gian nhưng việc sử dụng CPU dần dần tăng lên một lần nữa.

Trong tuần vừa qua, việc sử dụng CPU đã ở mức cao trong thập niên 90, đạt 100% hoặc đạt được một cách nhất quán vào ngày hôm qua, khiến trang web sản xuất của chúng tôi bị đình trệ. Sau khi khởi động lại máy chủ db, trong vòng vài giờ, việc sử dụng CPU đã tăng trở lại mức tương tự.

Tôi đã chạy danh sách quy trình chương trình trên máy chủ mysql và đã theo dõi tương tự thông qua quản trị viên MySQL. Dường như không có bất kỳ truy vấn nào đặc biệt dài hoặc một khối lượng truy vấn lớn. Có một vài quá trình nằm trong trạng thái ngủ trong một thời gian dài ... đây là những daemon công nhân bị cô lập chạy bên ngoài ứng dụng chính của chúng tôi giao tiếp với cơ sở dữ liệu. Tôi đã sao chép trong đầu ra danh sách quy trình bên dưới với tên máy chủ được thay đổi để đưa ra mô tả về chúng là gì:

+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+
| 13 | rdsadmin | localhost:43513 | mysql | Sleep | 14 | | NULL |
| 15 | proddbuser | app-server-1.eu-west-1.compute.internal:36460 | proddb | Sleep | 46 | | NULL |
| 451 | proddbuser | app-server-1.eu-west-1.compute.internal:55512 | proddb | Sleep | 29 | | NULL |
| 912 | proddbuser | app-server-1.eu-west-1.compute.internal:45171 | proddb | Sleep | 13 | | NULL |
| 941 | proddbuser | app-server-1.eu-west-1.compute.internal:47353 | proddb | Sleep | 53 | | NULL |
| 951 | proddbuser | app-server-1.eu-west-1.compute.internal:48014 | proddb | Sleep | 37 | | NULL |
| 1009 | proddbuser | app-server-1.eu-west-1.compute.internal:51787 | proddb | Sleep | 36 | | NULL |
| 1041 | proddbuser | app-server-1.eu-west-1.compute.internal:53777 | proddb | Sleep | 14 | | NULL |
| 1572 | proddbuser | app-server-1.eu-west-1.compute.internal:42989 | proddb | Sleep | 3 | | NULL |
| 1592 | proddbuser | app-server-1.eu-west-1.compute.internal:43279 | proddb | Sleep | 162 | | NULL |
| 2909 | proddbuser | app-server-1.eu-west-1.compute.internal:37768 | proddb | Sleep | 35 | | NULL |
| 3028 | proddbuser | app-server-1.eu-west-1.compute.internal:42568 | proddb | Sleep | 5 | | NULL |
| 3119 | proddbuser | app-server-1.eu-west-1.compute.internal:46913 | proddb | Sleep | 76 | | NULL |
| 3189 | proddbuser | app-server-1.eu-west-1.compute.internal:51466 | proddb | Sleep | 5 | | NULL |
| 3216 | proddbuser | app-server-2.eu-west-1.compute.internal:44097 | proddb | Sleep | 14552 | | NULL |
| 3218 | proddbuser | app-server-2.eu-west-1.compute.internal:44099 | proddb | Sleep | 14552 | | NULL |
| 3219 | proddbuser | app-server-2.eu-west-1.compute.internal:44107 | proddb | Sleep | 44 | | NULL |
| 3220 | proddbuser | app-server-2.eu-west-1.compute.internal:44113 | proddb | Sleep | 26 | | NULL |
| 3223 | proddbuser | app-server-2.eu-west-1.compute.internal:44184 | proddb | Sleep | 50 | | NULL |
| 3224 | proddbuser | app-server-2.eu-west-1.compute.internal:44187 | proddb | Sleep | 1 | | NULL |
| 3226 | proddbuser | app-server-2.eu-west-1.compute.internal:44208 | proddb | Sleep | 33 | | NULL |
| 3229 | proddbuser | app-server-2.eu-west-1.compute.internal:44250 | proddb | Sleep | 14 | | NULL |
| 3232 | proddbuser | app-server-2.eu-west-1.compute.internal:44279 | proddb | Sleep | 26 | | NULL |
| 3233 | proddbuser | app-server-2.eu-west-1.compute.internal:44297 | proddb | Sleep | 31 | | NULL |
| 3237 | proddbuser | app-server-2.eu-west-1.compute.internal:44334 | proddb | Sleep | 27 | | NULL |
| 3239 | proddbuser | app-server-2.eu-west-1.compute.internal:44338 | proddb | Sleep | 11 | | NULL |
| 3241 | proddbuser | app-server-2.eu-west-1.compute.internal:44356 | proddb | Sleep | 26 | | NULL |
| 3260 | proddbuser | app-server-2.eu-west-1.compute.internal:44619 | proddb | Sleep | 8 | | NULL |
| 3337 | proddbuser | utility-server-1.eu-west-1.compute.internal:45193 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 309416 LIMIT 1 |
| 3419 | proddbuser | utility-server-1.eu-west-1.compute.internal:46136 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 284530 LIMIT 1 |
| 3463 | proddbuser | app-server-1.eu-west-1.compute.internal:59619 | proddb | Sleep | 9406 | | NULL |
| 3504 | proddbuser | utility-server-1.eu-west-1.compute.internal:47063 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 260571 LIMIT 1 |
| 3577 | proddbuser | app-server-1.eu-west-1.compute.internal:34394 | proddb | Sleep | 6734 | | NULL |
| 3585 | proddbuser | utility-server-1.eu-west-1.compute.internal:47990 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 231273 LIMIT 1 |
| 3664 | proddbuser | utility-server-1.eu-west-1.compute.internal:48909 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 201525 LIMIT 1 |
| 3716 | proddbuser | app-server-2.eu-west-1.compute.internal:56301 | proddb | Sleep | 27 | | NULL |
| 3748 | proddbuser | utility-server-1.eu-west-1.compute.internal:49850 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 167839 LIMIT 1 |
| 3771 | proddbuser | my-pc:30101 | NULL | Query | 0 | NULL | show processlist |
| 3831 | proddbuser | utility-server-1.eu-west-1.compute.internal:50785 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 123228 LIMIT 1 |
+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+

Tôi cũng nên nói rằng lưu lượng truy cập trên trang web cực kỳ thấp trong giai đoạn này, so với giờ cao điểm bình thường, khoảng 10% tải chúng ta thấy vào thời gian cao điểm.

Chúng tôi cũng có giám sát di tích mới cho chúng tôi thấy các cuộc gọi cơ sở dữ liệu ứng dụng tốn thời gian nhất là gì. Nó cho chúng ta thấy rằng một cuộc gọi cụ thể chiếm 99% thời gian ứng dụng của chúng ta dành cho db là một tìm kiếm đơn giản bằng truy vấn id như thế này:

SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`id` = 123 LIMIT 1

(không hoàn toàn giống với các truy vấn đang chạy trong danh sách quy trình trên)

Hoạt động này đã trở nên chậm hơn trong tuần qua hoặc lâu hơn, với độ lệch chuẩn giữa các yêu cầu thời gian ngày càng tăng và cũng là lượng thời gian tối đa được tính theo giây. Tôi nghĩ rằng đây chỉ là kết quả của các vấn đề sử dụng CPU chứ không phải là nguyên nhân.

Bảng này có khoảng 80.000 hàng nên không lớn. Dự kiến, hầu hết thời gian của ứng dụng trong cơ sở dữ liệu được dành để tra cứu các bản ghi trong bảng này, chức năng chính của ứng dụng dựa trên điều này. Tôi đã tự chạy một truy vấn tương tự từ máy chủ ứng dụng của mình đến cơ sở dữ liệu sản xuất một vài lần, trong khi mức sử dụng CPU vẫn ở mức khoảng 100% và nó đáp ứng trong vòng 1 hoặc 2 ms.

Dựa trên tất cả những điều trên, chúng tôi không chắc chắn cách tiến hành gỡ lỗi. Chỉ tự hỏi nếu có ai có bất kỳ ý tưởng nào loại điều có thể là nguyên nhân gốc rễ và làm thế nào để điều tra những điều này? Quyền truy cập vào máy chủ cơ bản chạy máy chủ db của chúng tôi bị hạn chế do phiên bản Amazon RDS của nó.

Quản lý để giải quyết điều này, đây là các bước tôi đã làm theo:

Đầu tiên, tôi đã liên hệ với nhóm Amazon RDS bằng cách đăng lên diễn đàn thảo luận của họ, họ xác nhận đó là quá trình mysqld chiếm hết CPU này - điều này đã loại bỏ lỗi cấu hình với một thứ khác chạy trên máy chủ vật lý

Thứ hai, tôi đã theo dõi nguồn của các truy vấn đang chạy:

SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 231273 LIMIT 1 

Ban đầu tôi đã bỏ qua điều này là nguyên nhân, bởi vì không có truy vấn nào trong số những truy vấn này dường như mất nhiều thời gian khi tôi theo dõi kết quả đầu ra của danh sách quy trình. Sau khi cạn kiệt các con đường khác, tôi quyết định có thể đáng để theo dõi .... và tôi vui vì tôi đã làm vậy.

Như bạn có thể thấy trong đầu ra danh sách quy trình hiển thị, các truy vấn này đến từ một máy chủ không thể sử dụng, chạy một số công việc tiện ích chiến thuật tồn tại bên ngoài mã ứng dụng chính của chúng tôi. Đây là lý do tại sao chúng không hiển thị chậm hoặc gây ra sự cố trong giám sát di tích mới của chúng tôi, vì tác nhân di tích mới chỉ được cài đặt trên máy chủ ứng dụng chính của chúng tôi.

Nhẹ nhàng làm theo hướng dẫn này:

http://www.mysqlperformanceblog.com/2007/02/08/debugging-s ngủing -connections-with-mysql /

Tôi đã có thể theo dõi các truy vấn này đến một quy trình chạy cụ thể trên hộp máy chủ tiện ích của chúng tôi. Đây là một chút mã ruby ​​lặp đi lặp lại rất kém hiệu quả qua khoảng 70.000 bản ghi, kiểm tra một số giá trị trường và sử dụng chúng để quyết định xem nó có cần tạo bản ghi mới trong 'mytable' không. Sau khi thực hiện một số phân tích tôi đã có thể xác định, quá trình không còn cần thiết nên có thể bị giết.

Một cái gì đó đang làm cho vấn đề tồi tệ hơn, dường như có 6 trường hợp của cùng một quá trình này chạy cùng một lúc do cách thức công việc định kỳ được cấu hình và mỗi lần mất bao lâu! Tôi đã loại bỏ các quá trình này và thật không ngờ việc sử dụng CPU của chúng tôi đã giảm từ khoảng 100% xuống còn khoảng 5%!