Làm cách nào để tối ưu hóa bảng_cache?

Tôi đã tìm kiếm Google nhưng không thể tìm thấy câu trả lời chính xác. Một số có giá trị này ở mức 10000 hoặc thậm chí 20000. Những người khác nói rằng thậm chí 1000 là quá nhiều cho 1gb RAM. Tôi bối rối.

Số lượng của tôi opened_tablesđang tăng lên. Mysqltuner nói rằng tôi nên nâng cao table_cachegiá trị. Tôi đã cố gắng nâng nó lên 2K, rồi 3K, rồi 4K, sau đó tôi làm nó 512 để xem điều gì xảy ra. Đây là báo cáo:

Currently running supported MySQL version 5.0.67-community-nt-log
Operating on 32-bit architecture with less than 2GB RAM
Archive Engine Installed
Berkeley DB Engine Not Installed
Federated Engine Installed
InnoDB Engine Installed
ISAM Engine Not Installed
NDBCLUSTER Engine Not Installed
Data in InnoDB tables: 12M (Tables: 3)
Data in MEMORY tables: 380K (Tables: 2)
Data in MyISAM tables: 83M (Tables: 84)
Total fragmented tables: 16
All database users have passwords assigned
Up for: 16h 12m 55s (161K q [2.000 qps], 6K conn, TX: 281M, RX: 22M)
Reads / Writes: 69% / 31%
Total buffers: 128.0M global + 2.1M per thread (100 max threads)
Maximum possible memory usage: 334.3M (16% of installed RAM)
Slow queries: 1% (11/161K)
Highest usage of available connections: 10% (10/100)
Key buffer size / total MyISAM indexes: 32.0M/4.1M
Key buffer hit rate: 97% (849K cached / 20K reads)
Query cache efficiency: 28% (26K cached / 93K selects)
Query cache prunes per day: 0
Sorts requiring temporary tables: 1% (1 temp sorts / 21K sorts)
Temporary tables created on disk: 1% (2 on disk / 15K total)
Thread cache hit rate: 99% (10 created / 6K connections)
Table cache hit rate: 5% (139 open / 2K opened)
Open file limit used: 20% (232/1K)
Table locks acquired immediately: 99% (116K immediate / 116K locks)
InnoDB data size / buffer pool: 12.5M/32.0M
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Increase table_cache gradually to avoid file descriptor limits
table_cache (> 512)
Scan Complete

mysql> show global STATUS LIKE 'open%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_files    | 222   |
| Open_streams  | 0     |
| Open_tables   | 127   |
| Opened_tables | 2335  |
+---------------+-------+
4 rows in set (0.00 sec)

Tuy nhiên, opened_tablesvẫn đang phát triển. Tôi có nên nuôi nó một lần nữa? Hay là nó không đáng quan tâm?

Ngoài ra, một số người nói rằng vấn đề thường là trong việc tạo ra nhiều bảng tạm thời. Như chúng ta có thể thấy từ các số liệu thống kê, đó không phải là trường hợp của tôi. Tỷ lệ giữa table_cachevà RAM là gì?

Lý do bạn không tìm thấy câu trả lời là không có câu trả lời. Giá trị phù hợp table_cachekhông tương quan với một lượng bộ nhớ hệ thống.

Lưu ý rằng table_cacheđã được đổi tên table_open_cache trong MySQL 5.1.3 và được gọi bằng tên mới trong các phiên bản mới hơn của MySQL.

Như tôi đã đề cập trong câu trả lời của mình cho câu hỏi gần đây tương tự này , trong số những điều có thể tăng lên opened_tables, một số trong số chúng đều vô hại và không thể tránh khỏi (chẳng hạn như tạo bản sao lưu với mysqldump, trong hầu hết các trường hợp, phát hành một số biến thể FLUSH TABLES, làm tăng các bộ đếm như mỗi bảng được mở lại sau khi xả, với mục đích sao lưu bảng hoặc bởi các luồng khách khác truy cập vào các bảng được xóa gần đây, phải được mở lại một cách tự nhiên).

Điều tôi không nghĩ sẽ đề cập đến trong bài đăng đó là - và tôi tin rằng bạn sẽ tìm thấy một số biện pháp giải trí trong việc này - rằng hành động chạy mysqltuner đối với máy chủ của bạn có thể, làm tăng bộ opened_tablesđếm, do đó làm mất hiệu lực kết quả của chính nó .

Một người bình luận về câu trả lời của tôi đã tham khảo bài viết này , trong đó tác giả chỉ ra rằng việc điều chỉnh table_cachelàm giảm hiệu suất khi bạn đặt nó "tối ưu" hơn.

Điểm mấu chốt là đây là một ví dụ tốt về một biến được để riêng một mình trừ khi bạn có một lý do cụ thể để điều chỉnh nó và đầu ra của một tập lệnh điều chỉnh không được tính. Các kịch bản điều chỉnh thường có chủ ý tốt nhưng đôi khi đó là điều tốt nhất có thể nói về chúng:

Vấn đề với các mối tương quan đôi khi có vẻ đúng là mọi người bắt đầu tin rằng họ sẽ luôn luôn đúng. Các DBA của Oracle đã từ bỏ điều chỉnh dựa trên tỷ lệ nhiều năm trước và chúng tôi mong muốn các DBA của MySQL sẽ đi theo sự dẫn dắt của họ.

Chúng tôi mong muốn thậm chí còn nhiệt thành hơn nữa rằng mọi người sẽ không viết các kịch bản điều chỉnh của Google, mã hóa các thực hành nguy hiểm này và dạy chúng cho hàng ngàn người. Điều này dẫn đến gợi ý thứ hai của chúng tôi về những điều không nên làm: không sử dụng các tập lệnh điều chỉnh! Có một số cái rất phổ biến mà bạn có thể tìm thấy trên Internet. Có lẽ tốt nhất là bỏ qua chúng.

Chúng tôi cũng khuyên bạn nên tránh điều chỉnh từ, điều mà chúng tôi đã sử dụng một cách tự do trong vài đoạn trước. Thay vào đó, chúng tôi ưu tiên cấu hình và các ứng dụng tối ưu hóa cấu hình của cải tiến (miễn là đó là những gì bạn đang làm; xem Chương 3). Từ điều chỉnh tinh chỉnh gợi lên hình ảnh của một người mới vô kỷ luật, người điều chỉnh máy chủ và xem điều gì sẽ xảy ra. Chúng tôi đã đề xuất trong phần trước rằng thực hành này là tốt nhất để lại cho những người đang nghiên cứu nội bộ máy chủ.

Điều chỉnh máy chủ của bạn có thể là một sự lãng phí thời gian tuyệt vời.

^{- Schwartz, Nam tước; Zaitsev, Peter; Tkachenko, Vadim (2012 / 03-05). MySQL hiệu suất cao: Tối ưu hóa, sao lưu và sao chép (Địa điểm Kindle 12173-12182). OReilly Media - A. Phiên bản Kindle.}

Như một lưu ý phụ, MySQL 5.0 đã hết tuổi thọ. MySQL 5.0.67 đã được phát hành hơn 4 năm trước và một số lỗi đáng kể đã được sửa trong loạt phát hành 5.0 kể từ đó. Nếu tôi có một máy chủ 5.0.67 và nó đang hoạt động, thì điều cuối cùng tôi muốn làm là thay đổi bất cứ điều gì về cấu hình của nó.

Bạn đang mở ít hơn 1 bàn mỗi giờ . Điều đó là không đáng kể .

Các số liệu nên được xem xét là Opened_tables / Uptime. Đó là "mỗi giây".

Tôi đề nghị rằng bất cứ điều gì dưới 2 / giây là tốt.

Quay lại câu hỏi tiêu đề:

Cân nhắc tăng table_open_cachenếu

Opened_tables / Uptime > 2
Opened_table_definitions / Uptime > 1
Table_open_cache_misses / Uptime > 1
Table_open_cache_overflows / Uptime > 1
Open_tables = table_open_cache

Nếu bạn không thể nâng nó lên, hãy kiểm tra open_files_limitvà giới hạn hệ điều hành.

Nếu MySQL của bạn đủ mới, hãy đặt table_open_cache_instances(có lẽ) số lượng lõi bạn có.

Có thể là do ứng dụng của bạn có thể khiến MySQL tạo các bảng tmp nếu giá trị Open_tables thấp hơn giá trị table_open_cache. Tạo bảng tmp cũng tăng bộ đếm Opened_tables. Tôi cũng chạy tập lệnh Mysqltuner và nhận thấy tỷ lệ nhấn bộ đệm trong bảng dưới 50%. Tôi đã tự hỏi tại sao nó không sử dụng không gian bộ nhớ cache miễn phí có sẵn, nhưng số lượng vẫn tiếp tục tăng. Cuốn sách tương tự được Michael tham khảo giải thích nó. MySQL hiệu suất cao: Tối ưu hóa, sao lưu và sao chép

Nó phụ thuộc vào việc đó là Linux hay Windows.

Đối với Windows có kết nối mặc định, giá trị không thể lớn hơn (2048-100) / 2 = 976, do bảng mở x 2 + kết nối cần nhỏ hơn 2048. Trình xem sự kiện Windows của bạn sẽ cho bạn biết nếu bạn định cấu hình sai nó

Trên linux, giá trị có thể cao hơn nhiều, do nó có giới hạn mô tả tệp cao hơn nhiều. Bạn có thể tăng giới hạn bằng cách tăng ulimit.