Sử dụng CPU cao của MySQL [đã đóng]

191

Gần đây CPU máy chủ của tôi đã tăng rất cao.

Tải CPU trung bình 13,91 (1 phút) 11,72 (5 phút) 8,01 (15 phút) và trang web của tôi chỉ có lưu lượng truy cập tăng nhẹ.

Sau khi chạy một lệnh hàng đầu, tôi thấy MySQL đang sử dụng CPU 160%!

Gần đây tôi đã tối ưu hóa các bảng và tôi đã chuyển sang các kết nối liên tục. Điều này có thể khiến MySQL sử dụng số lượng lớn CPU?

mysql cpu-usage

— Đánh rối
nguồn

Các kết nối liên tục hầu như không phải là thứ phù hợp để sử dụng.

— jason

Tôi sẽ gỡ chúng ra bây giờ và xem sự khác biệt bởi vì tôi không bao giờ nhớ cpu đã ở trên 2 tháng trước!

— Đánh bóng

Máy chủ có xu hướng có nhiều hơn một lõi. Phần trăm sử dụng CPU được tính tương đối với một lõi, một từ khác, một quá trình sử dụng hoàn toàn hai lõi sẽ có mức sử dụng CPU là 200%. Ở đây, MySQL đang sử dụng tối đa 100% một lõi và 60% của một lõi khác. Điều đó không có nghĩa là tất cả các CPU đều được sử dụng hết, rất có thể anh ta vẫn còn ít nhất hai CPU miễn phí.

— xaav

CPU cao hầu như luôn có nghĩa là truy vấn không hiệu quả. Điều này thường được giải quyết thông qua việc lập chỉ mục tốt hơn (đặc biệt là 'tổng hợp') và / hoặc cải tổ truy vấn.

— Rick James

Câu trả lời:

265

Đầu tiên tôi muốn nói rằng bạn có thể muốn tắt các kết nối liên tục vì chúng hầu như luôn gây hại nhiều hơn là tốt.

Thứ hai, tôi muốn nói rằng bạn muốn kiểm tra kỹ người dùng MySQL của mình, chỉ để đảm bảo rằng không ai có thể kết nối từ máy chủ từ xa. Đây cũng là một điều an ninh chính để kiểm tra.

Thứ ba, tôi muốn nói rằng bạn muốn bật Nhật ký truy vấn chậm của MySQL để theo dõi mọi truy vấn đang mất nhiều thời gian và sử dụng điều đó để đảm bảo bạn không có bất kỳ truy vấn nào khóa các bảng chính quá lâu.

Một số điều khác bạn có thể kiểm tra sẽ là chạy truy vấn sau trong khi tải CPU cao:

SHOW PROCESSLIST;

Điều này sẽ cho bạn thấy bất kỳ truy vấn nào đang chạy hoặc trong hàng đợi để chạy, truy vấn đó là gì và đang làm gì (lệnh này sẽ cắt ngắn truy vấn nếu quá dài, bạn có thể sử dụng SHOW FULL PROCESSLIST để xem toàn bộ văn bản truy vấn) .

Bạn cũng sẽ muốn giữ một mắt trên những thứ như kích thước bộ đệm, bạn nhớ cache bảng , bộ nhớ cache truy vấn và innodb_buffer_pool_size (nếu bạn đang sử dụng InnoDB bảng) như tất cả các cấp phát bộ nhớ có thể có ảnh hưởng đến hiệu suất truy vấn có thể gây MySQL để Ăn hết CPU.

Bạn cũng có thể muốn đọc những điều sau đây vì chúng chứa một số thông tin tốt.

Đó cũng là một ý tưởng rất tốt để sử dụng một hồ sơ. Một cái gì đó bạn có thể bật khi bạn muốn sẽ cho bạn biết những truy vấn nào mà ứng dụng của bạn đang chạy, nếu có các truy vấn trùng lặp, chúng mất bao lâu, v.v. Một ví dụ về một cái gì đó giống như cái này tôi đã làm việc được gọi PHP Profiler nhưng có rất nhiều ngoài kia. Nếu bạn đang sử dụng một phần mềm như Drupal, Joomla hoặc Wordpress, bạn sẽ muốn hỏi xung quanh cộng đồng vì có thể có các mô-đun có sẵn cho họ để bạn có được thông tin này mà không cần phải tích hợp thủ công.

— Steven Surowiec
nguồn

cảm ơn rất nhiều vì điều này, tôi đã xóa các kết nối liên tục và sau đó thiết lập nhật ký truy vấn chậm. tôi đọc nhật ký và hầu hết các truy vấn đến từ hai bảng và các bảng chưa được lập chỉ mục đúng! chỉ mất khoảng 10 phút nhưng đây là kết quả: CPU tải trung bình 0,48 (1 phút) 0,95 (5 phút) 2,42 (15 phút) cảm ơn rất nhiều

— Đánh bóng

cùng một vấn đề, được giải quyết bằng cách lập chỉ mục các bảng làm chậm quá trình, cảm ơn bạn Steven và Juddling

— gabrielem

@Juddling Bạn có thể giải thích cách lập chỉ mục một bảng không? Có lẽ một số liên kết? Tôi biết nó đã được một thời gian, nhưng tôi thực sự mới với điều này. Xin lỗi vì câu hỏi

— ngớ ngẩn

Ghi nhật ký các truy vấn chậm giúp tôi tìm ra vấn đề cụ thể của mình về việc sử dụng CPU cao. Trong trường hợp của tôi, đó là một plugin Wordpress (widget cuối cùng của thẻ đám mây) đang thực hiện một truy vấn khủng khiếp với mỗi lần nhấn chỉ để hiển thị các thẻ phổ biến. Đó là một plugin tuyệt vời, nhưng cần phải được tăng cường với một số loại bộ nhớ đệm (cuối cùng tôi đã tùy chỉnh nó để giải quyết vấn đề của mình).

— jkincali

Một điều khác đã giúp một vấn đề khác là sửa đổi tham số innodb_buffer_pool_size đã đề cập ở trên. Trong khi cố gắng tìm ra nguyên nhân của việc sử dụng CPU cao, tôi đã đọc ở đâu đó rằng innodb_buffer_pool_size nên có kích thước tối thiểu của tệp ibdata1, nằm trong / var / lib / mysql. Có vẻ như InnoDB hoạt động hiệu quả hơn nhiều khi có thể nằm trong bộ nhớ. Điều này có thể khó thực hiện trong một số tình huống vì ibdata1 có thể rất lớn! Nó cũng được đề xuất ở đâu đó để đảm bảo innodb_log_buffer_size bằng 25% kích thước của innodb_buffer_pool_size.

— jkincali

167

Vì đây là bài đăng hàng đầu nếu bạn google cho việc sử dụng hoặc tải CPU cao của MySQL, tôi sẽ thêm một câu trả lời:

Vào ngày 1 tháng 7 năm 2012, một bước nhảy vọt thứ hai đã được thêm vào thời gian UTC hiện tại để bù đắp cho sự quay chậm của trái đất do thủy triều. Khi chạy ntp (hoặc ntpd), giây này đã được thêm vào đồng hồ của máy tính / máy chủ của bạn. MySQLd dường như không thích thứ hai thêm này trên một số hệ điều hành và mang lại tải CPU cao. Cách khắc phục nhanh là (dưới quyền root):

$ /etc/init.d/ntpd stop
$ date -s "`date`"
$ /etc/init.d/ntpd start

— RedPixel
nguồn

Vì bài đăng gốc là khoảng 3 năm trước, tôi nghi ngờ đó là nguyên nhân của vấn đề của người đăng bài gốc. Nhưng đó là nguyên nhân của vấn đề của tôi và đã cứu tôi ngay bây giờ - cảm ơn! Thông tin thêm: blog.mozilla.org/it/2012/06/30/ khăn

— Russell G

Vấn đề & giải pháp tương tự cho tôi trên Ubuntu 12.04. Các bước để giải quyết hơi khác nhau: dịch vụ ntp stop && date -s " date" && dịch vụ ntp bắt đầu sử dụng CPU MySQL ngay lập tức giảm từ 50 - 100% xuống 0 - 1%

— David Laing

Điều này có thể được thực hiện chỉ để đảm bảo? Ý tôi là, nó có an toàn để chạy nó ngay cả khi nó không phải là lý do?

— Muhammad Gelbana

Ngày 1 tháng 7 năm 2015 - Tôi vừa trải qua lỗi thứ hai rất nhảy vọt này trên máy chủ AWS EC2 hiện tại đang chạy Amazon Linux. Sử dụng sudo service ntpd stoptrên cấu hình này.

— Matt van Andel

+1 cho giải pháp này. MySQL của tôi đã chạy ở mức 50-60% trong nhiều tháng mà không có lý do, sau khi áp dụng giải pháp này, nó đã giảm xuống còn 0,0-0,3%, đó là cách nó được sử dụng. Cảm ơn rất nhiều.

— zeeshan

Nếu máy chủ này hiển thị với thế giới bên ngoài, bạn nên kiểm tra xem nó có nhiều yêu cầu kết nối từ thế giới bên ngoài không (tức là mọi người đang cố gắng xâm nhập vào nó)

— Shawland Shaw
nguồn

Không chắc chắn lý do tại sao điều này thu hút một downvote ẩn danh, vì điều này đã là một nguyên nhân trong quá khứ cho một số hệ thống.

— Rowland Shaw

Tôi nghĩ rằng việc bỏ phiếu giảm là vì việc MySQL hiển thị với thế giới bên ngoài không phải là một ý tưởng hay.

— MikeKulls

@MikeKulls Không, đó không phải là một ý tưởng hay, vì nó sẽ đóng vai trò là mục tiêu để nhiều người thử và đạt được mục nhập, điều này sẽ cho tải CPU cao - vì vậy câu trả lời của tôi là một lý do có thể.

— Rowland Shaw

Tôi ghét nó khi ai đó chỉ cần bỏ phiếu và đi!

— Muhammad Gelbana

+1 vì đây hoàn toàn là một lý do chính đáng để MySQL có mức sử dụng CPU cao và bất kỳ ai là câu trả lời thực sự cần thông tin này!

— Chris Browne