MySQL bảng_cache và Opened_tables

Tôi đã thấy mọi người sử dụng so sánh Open_tables và Opened_tables để đánh giá xem bảng_cache có quá nhỏ trong MySQL không. Tuy nhiên, tôi tin rằng Opened_tables được tích lũy theo thời gian hoạt động, vì vậy đây không phải là một so sánh hợp lệ. Nhắc nhở duy nhất là có lẽ Opened_tables chỉ bị lỗi do bỏ lỡ - mặc dù sau đó nếu các bảng được mở mỗi giây vẫn còn nhỏ, có lẽ nó không phải là vấn đề để nó tăng dần.

Nếu so sánh Open_tables với Opened_tables không hợp lệ, có cách nào khác để lấy dữ liệu đo cho việc này không?

Đây là trên MySQL 5.0, nhưng sự khác biệt giữa các phiên bản cũng được chào đón.

Lý do lớn nhất để có một bảng_cache lớn là để mutex LOCK_open không nóng. MySQL trước 5.5 có rất nhiều tranh cãi khi bạn đang cố mở / đóng bảng, vì vậy bạn muốn hạn chế làm điều này càng nhiều càng tốt, tức là có bộ đệm bảng lớn.

Vì vậy, bạn không quan tâm đến bất kỳ tỷ lệ truy cập cụ thể nào để bỏ lỡ (nguyên nhân bạn nên bỏ qua các tỷ lệ hoàn toàn - bài đăng trên blog này giải thích lý do tại sao ). Điều bạn quan tâm là tỷ lệ bỏ lỡ , bởi vì điều này xảy ra càng nhiều lần mỗi giây, khả năng bạn sẽ có sự tranh chấp càng cao (một luồng phải chờ một luồng khác giải phóng khóa.)

Làm thế nào để bạn phát hiện tỷ lệ bỏ lỡ? Bạn tìm nạp một vài mẫu Opened_Tables cách nhau vài giây trong khoảng thời gian bận rộn nhất trong ngày và nếu có sự gia tăng trong mỗi mẫu, có lẽ bạn nên xem liệu bạn có thể tăng bảng_cache không.

Lưu ý: Tôi đặc biệt không khuyên bạn nên so sánh với thời gian hoạt động.

Trước tiên, hãy xem xét các biến trạng thái:

Bảng mở : Số lượng bảng đang mở.

Opened_tables : Số lượng bảng đã được mở. Nếu Opened_tables lớn, giá trị table_open_cache của bạn có thể quá nhỏ.

Đáng ngạc nhiên, câu trả lời cho câu hỏi của bạn nằm trong chính câu hỏi.

Hai biến sẽ chỉ có ý nghĩa hơn nếu bạn ném thêm một biến trạng thái vào hỗn hợp: Uptime (hoặc Uptime_since_flush status cho mức trung bình mới sau FLAT STATUS ).

Bạn nên so sánh Open_tables agsinst (Opened_tables / Uptime) . Nếu Open_tables leo lên trên (Opened_tables / Uptime) , thì bây giờ bạn có lý do để lo lắng và nên để mắt đến những thứ như sau:

• netstat
• i điều hòa
• tải máy chủ
• Số lượng kết nối (khi nó đến gần max_connections )
• Khách hàng bị hủy bỏ
• Đã hủy kết nối
• Truy vấn chậm

CẬP NHẬT 2011-08-31 12:18 EDT

Xin lưu ý tại sao tôi cũng đề xuất sử dụng Uptime_since_flush_status thay vì Uptime để sửa lỗi mô hình tăng trưởng Opened_tables trong một khoảng thời gian nhất định.

Ví dụ: nếu bạn chạy FLUSH STATUS;mỗi thứ Hai vào lúc nửa đêm, bạn có thể tạo OpenTableFactor:

SELECT *, (Open_tables * Uptime / Opened_Tables) OpenTableFactor FROM
(SELECT variable_value Uptime FROM information_schema.global_status
WHERE variable_name = 'Uptime_since_flush_status') up,
(SELECT variable_value Open_tables FROM information_schema.global_status
WHERE variable_name = 'Open_tables') opn,
(SELECT IF(variable_value=0,1,variable_value) Opened_tables
FROM information_schema.global_status
WHERE variable_name = 'Opened_tables') opnd;

Hệ số bảng mở này tương đương với số đại diện cho số lượng bảng mở tại bất kỳ thời điểm nào so với số lượng bảng mở trung bình trong suốt một khoảng thời gian nhất định. Với mộtFLUSH HOSTS; mỗi tuần / ngày / máy chủ, trung bình đó là so với tuần / ngày / giờ.

Đây là một mẫu từ một trong những khách hàng của chủ nhân của tôi:

mysql> SELECT *, (Open_tables * Uptime / Opened_Tables) OpenTableFactor FROM     (SELECT variable_value Uptime FROM information_sc    hema.global_status     WHERE variable_name = 'Uptime_since_flush_status') up,     (SELECT variable_value Open_tables FROM informat    ion_schema.global_status     WHERE variable_name = 'Open_tables') opn,     (SELECT IF(variable_value=0,1,variable_value) Opened_ta    bles     FROM information_schema.global_status     WHERE variable_name = 'Opened_tables') opnd;
+----------+-------------+---------------+-------------------+
| Uptime   | Open_tables | Opened_tables | OpenTableFactor   |
+----------+-------------+---------------+-------------------+
| 14385123 | 16326       | 30429078      | 7717.996519579068 |
+----------+-------------+---------------+-------------------+
1 row in set (0.00 sec)

Ứng dụng khách này thường duy trì khoảng 7745 OpenTableFactor tối đa. Nếu OpenTableFactor giảm đột ngột (dù chỉ một chút), nó có thể chỉ ra các mẫu lưu lượng truy cập thấp hơn, các mức độ bị hủy bỏ cao, v.v. Nếu OpenTableFactor không bao giờ thay đổi (dù chỉ một chút), nó có thể cho bạn cơ hội thay đổi các cài đặt này:

• open_files_limit
• innodb_open_files
• bảng_open_cache

Sau khi được điều chỉnh, OpenTableFactor có thể thay đổi liên tục hoặc chạm vào trần hoặc cao nguyên khác. Do đó, việc sử dụng các đơn vị khác nhau trong các biến trạng thái trở nên quan trọng đối với loại điều chỉnh này.

CẬP NHẬT 2011-08-31 12:42 EDT

Truy vấn SQL tôi đã chạy cho OpenTableFactor không hoạt động cho MySQL 5.0 trở lại. Nếu bạn đang sử dụng Quản trị viên MySQL hoặc MONyog , bạn có thể tùy chỉnh biểu đồ bằng công thức trong truy vấn và theo dõi. MONyog thu thập lịch sử bằng cách sử dụng SQLLite để vẽ đồ thị lịch sử sau này. Điều này có thể được thực hiện cho bất kỳ phiên bản nào của MySQL.

Từ một trong những bình luận của người dùng trên trang tài liệu table_cache :

Opened_tables là một biến trạng thái giúp kiểm soát số lượng các bộ mô tả tệp bổ sung đã được phân bổ để mở các bảng tại thời điểm khi các bộ mô tả tệp có sẵn trong bảng_cache đã bị cạn kiệt. ...

Có nghĩa là nó được tăng lên khi bạn đi qua table_cachegiá trị của bạn . Vì vậy, cách tôi thường kiểm tra điều này là so sánh opened_tablesvới uptime, nhưng chìa khóa ở đây là đưa nó qua một khoảng thời gian đã đặt (ví dụ một lần mỗi phút trong mười phút chẳng hạn). Nếu nó tăng thì đó có thể là một dấu hiệu bạn cần tăng table_cache.

Một vài cảnh báo cần đề cập:

• Một nhận xét khác trong tài liệu đó ở trên: "Biến trạng thái 'Opened_tables' cũng sẽ được tăng thêm 2 mỗi khi bạn tạo một bảng tạm thời." Vì vậy, nếu các truy vấn của bạn yêu cầu nhiều bảng tạm thời, đây có thể là nguyên nhân của sự gia tăng nhanh chóng opened_tables. Bạn có thể thấy việc sử dụng bảng tạm thời của mình bằng cách sử dụng truy vấn sau:

  SHOW GLOBAL STATUS LIKE '%tmp%';

• Đừng tăng bảng_cache quá cao

  Lý do cho hành vi như vậy là, nếu bạn có lớn không. trong số các bảng có truy vấn phức tạp nối nhiều bảng và nhiều kết nối chạy các truy vấn phức tạp đó, cuối cùng bạn có thể sử dụng tất cả bộ đệm của bộ mô tả tệp (table_cache) trong trường hợp đó MySQL sử dụng thuật toán để tìm bộ mô tả ít được sử dụng gần đây nhất, đóng nó và thay thế nó với một mô tả mới.