Tại sao các chủ đề của MySQL thường hiển thị các mục miễn phí trong trạng thái của Google khi bộ đệm truy vấn bị tắt?

Khi tôi chạy SHOW PROCESSLIST, thường có một số lượng lớn các luồng INSERT / UPDATE ở trạng thái "giải phóng các mục".

Hướng dẫn sử dụng MySQL gợi ý rằng ít nhất một phần lý do khiến một luồng ở trạng thái này liên quan đến bộ đệm truy vấn - có lẽ nó sẽ làm mất hiệu lực các truy vấn được lưu trong bộ nhớ cache do dữ liệu đã thay đổi.

Tuy nhiên, của tôi query_cache_sizeđược đặt thành 0 sẽ vô hiệu hóa hoàn toàn bộ đệm truy vấn.

Những lý do nào khác sẽ có rất nhiều chủ đề trong trạng thái này?

Các bảng có liên quan sử dụng công cụ lưu trữ InnoDB.

Kiểm tra giá trị của innodb_thread_concurrency.

Đối với hệ thống của tôi, việc tăng giá trị từ 8 lên 32, theo hướng dẫn trong tài liệu MySql , đã gây ra sự sụt giảm rõ rệt về số lượng luồng xử lý đồng thời báo cáo trạng thái "giải phóng mặt hàng". Ngoài ra, thời gian truy vấn trung bình bị bỏ qua giảm theo một độ lớn.

Mặc dù điều này tạo ra sự khác biệt lớn trong hiệu suất tổng thể của máy chủ, nhưng nó không phải là viên đạn bạc "giải phóng vật phẩm". Hệ sinh thái phần cứng của tôi khiến tôi đưa ra giả thuyết rằng trạng thái này hầu hết được nhìn thấy trên các hệ thống có đĩa "chậm" (đĩa 2x10k đột kích 1) và ít phổ biến hơn trên các hệ thống có lưu trữ nhanh hơn (đĩa 12x15k đột kích 10). Vì vậy, kiểm tra hiệu suất đĩa cũng có thể được bảo hành.

Chúc may mắn!

Cũng thế:

Điều đáng chú ý là giá trị mặc định của innodb_thread_concurrency hoàn toàn khác nhau tùy thuộc vào việc phát hành 5.0 điểm nào đang được sử dụng.

Giá trị mặc định đã thay đổi nhiều lần: 8 trước MySQL 5.0.8, 20 (vô hạn) từ 5.0.8 đến 5.0.18, 0 (vô hạn) từ 5.0.19 đến 5.0.20 và 8 (hữu hạn) từ 5.0.21 trên. - nguồn

Điều này có nghĩa là một bản nâng cấp dường như vô hại từ 5.0.20 đến 5.0.21 đã thay đổi mặc định từ vô hạn thành 8 và mang theo sự phân nhánh hiệu suất.

Giải phóng các mục là một giai đoạn thực hiện truy vấn trong đó các cấu trúc tạm thời, bộ đệm, v.v ... được giải quyết. Một số công việc bộ đệm truy vấn được thực hiện trong giai đoạn này, nhưng đó không phải là điều duy nhất xảy ra ở đó. Tôi sẽ đề nghị sử dụng HỒ SƠ HỒ SƠ để xem giai đoạn này diễn ra trong bao lâu so với các giai đoạn khác và nếu thời gian tiêu tốn kết thúc là một mối lo ngại, hãy khắc phục sự cố bằng các công cụ như trình biên dịch và oprofile của người nghèo.

Có một báo cáo lỗi về vấn đề này liên quan đến "giải phóng các mục" và bộ đệm truy vấn . Mặc dù lỗi đã được đóng, nhưng không có đề cập đến innodb_thread_concurrency .

Thật tình cờ, tôi đã nói chuyện với Ronald Bradford tại Percona Live NYC hồi tháng Năm. Tôi đã nói với anh ấy về một tình huống mà tôi đã xử lý innodb_thread_concurrency vì nhiều bộ đệm InnoDB của MySQL 5.5 đã tạo ra vô số khóa luồng và tôi nghi ngờ rằng dữ liệu được lưu trong bộ nhớ cache mà tôi cần nhất có thể đã lan truyền trong nhiều nhóm bộ đệm.

Anh ấy nói thẳng với tôi rằng tôi không bao giờ nên đặt giá trị chống lại innodb_thread_concurrency. Đặt nó luôn là giá trị mặc định, bây giờ là 0 (0). Bằng cách đó, bạn để cho bộ lưu trữ InnoDB quyết định có bao nhiêu innodb_concurrency_tickets tự tạo. Đây là những gì đồng thời vô hạn làm.

'Giải phóng các mặt hàng' rất có thể xảy ra thường xuyên hơn khi chúng tôi áp đặt các giới hạn đối với innodb_thread_concurrency. Đó phải luôn là 0 (0). Tôi sẽ chấp nhận rủi ro và tăng innodb_concurrency_tickets và xem liệu nó có giúp ích hay không.

Chúng tôi đã có một vấn đề với các triệu chứng giống hệt nhau. Hóa ra đĩa chứa các tệp nhật ký InnoDB đã được lấp đầy. Đáng để kiểm tra.

Một gợi ý khác: Có thể là innodb fsync (). Thử cài đặt

innodb_flush_log_at_trx_commit = 2

Trong my.cnf

Logfile innodb sau đó được xóa vào đĩa cứ sau 1-2 giây, thay vào đó là ob ở mỗi lần xác nhận. Hình phạt nhẹ để toàn vẹn dữ liệu, đạt được tốc độ lớn.