Wie optimiere ich table_cache?

Ich habe bei Google gesucht, aber keine genaue Antwort gefunden. Einige haben diesen Wert bei 10000 oder sogar 20000. Andere sagen, dass sogar 1000 für 1 GB RAM zu viel ist. Ich bin verwirrt.

Meine Zahl opened_tableswächst. Mysqltuner sagt, ich sollte den table_cacheWert erhöhen . Ich habe versucht, es auf 2K, dann auf 3K, dann auf 4K zu erhöhen, dann habe ich es auf 512 gebracht, um zu sehen, was passiert. Hier ist der Bericht:

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)

opened_tablesWächst jedoch immer noch. Soll ich es noch einmal erhöhen? Oder ist es keine Aufmerksamkeit wert?

Darüber hinaus sagen einige Leute, dass das Problem normalerweise darin besteht, viele temporäre Tabellen zu erstellen. Wie wir aus den Statistiken sehen können, ist das nicht mein Fall. Wie ist das Verhältnis zwischen table_cacheund RAM?

Der Grund, warum Sie keine Antwort gefunden haben, ist, dass es keine Antwort gibt. Der entsprechende Wert für table_cachekorreliert nicht mit der Größe des Systemspeichers.

Beachten Sie, dass table_cacheumbenannt wurde table_open_cache in MySQL 5.1.3 in neueren und bezeichnet Versionen von MySQL durch den neuen Namen ein .

Wie ich in meiner Antwort auf diese ähnliche aktuelle Frage erwähnt habe , opened_tablessind einige der Dinge, die inkrementiert werden können , sowohl harmlos als auch unvermeidlich (z. B. das Erstellen von Backups mit mysqldump, die in den meisten Fällen eine Variante von FLUSH TABLESausgeben, die die Zähler als erhöht Jede Tabelle wird nach dem Leeren erneut geöffnet, entweder zum Sichern der Tabelle oder durch andere Client-Threads, die auf die kürzlich geleerten Tabellen zugreifen, die natürlich erneut geöffnet werden müssen.

Was ich in diesem Beitrag nicht erwähnen wollte, ist - und ich vertraue darauf, dass Sie darin ein gewisses Maß an Belustigung finden -, dass das Ausführen von mysqltuner gegen Ihren Server selbst den opened_tablesZähler erhöhen und somit seine eigenen Ergebnisse ungültig machen kann .

Ein Kommentator zu meiner Antwort verwies auf diesen Artikel , in dem der Autor darauf hinweist, dass das Optimieren die table_cacheLeistung verschlechtert, je "optimaler" Sie sie einstellen.

Unter dem Strich ist dies ein gutes Beispiel für eine Variable, die am besten in Ruhe gelassen wird, es sei denn, Sie haben einen bestimmten Grund, sie zu optimieren, und die Ausgabe eines Optimierungsskripts zählt nicht. Optimierungsskripte sind oft gut gemeint, aber das ist manchmal das Beste, was man über sie sagen kann:

Das Problem mit Korrelationen, die manchmal als wahr erscheinen, ist, dass die Leute anfangen zu glauben, dass sie immer wahr sein werden. Oracle-Datenbankadministratoren haben das verhältnisbasierte Tuning vor Jahren aufgegeben, und wir wünschen uns, dass MySQL-Datenbankadministratoren ihrem Beispiel folgen.

Wir wünschen uns noch mehr, dass die Leute keine „Tuning-Skripte“ schreiben, die diese gefährlichen Praktiken kodifizieren und sie Tausenden von Menschen beibringen. Dies führt zu unserem zweiten Vorschlag, was nicht zu tun ist: Verwenden Sie keine Tuning-Skripte! Es gibt einige sehr beliebte, die Sie im Internet finden können. Es ist wahrscheinlich am besten, sie zu ignorieren.

Wir empfehlen Ihnen außerdem, das Wort „Tuning“ zu vermeiden, das wir in den letzten Absätzen großzügig verwendet haben. Wir bevorzugen stattdessen "Konfiguration" oder "Optimierung" (solange Sie dies tatsächlich tun; siehe Kapitel 3). Das Wort „Tuning“ zaubert Bilder eines undisziplinierten Neulings, der den Server optimiert und sieht, was passiert. Wir haben im vorherigen Abschnitt vorgeschlagen, diese Vorgehensweise am besten denjenigen zu überlassen, die Server-Interna untersuchen.

Das "Optimieren" Ihres Servers kann eine erstaunliche Zeitverschwendung sein.

^{- Schwartz, Baron; Zaitsev, Peter; Tkachenko, Vadim (05.03.2012). Hochleistungs-MySQL: Optimierung, Sicherung und Replikation (Kindle Locations 12173-12182). OReilly Media - A. Kindle Edition.}

Als Randnotiz ist MySQL 5.0 das Ende des Lebens. MySQL 5.0.67 wurde vor über 4 Jahren veröffentlicht und seitdem wurde eine erhebliche Anzahl von Fehlern in der 5.0-Release-Serie behoben. Wenn ich einen 5.0.67-Server hätte und dieser funktioniert, würde ich als letztes etwas an seiner Konfiguration ändern wollen .

Sie öffnen weniger als 1 Tisch pro Stunde . Das ist unbedeutend .

Die Metrik, die hätte betrachtet werden sollen, ist Opened_tables / Uptime. Das ist "pro Sekunde".

Ich schlage vor, dass alles unter 2 / Sek. In Ordnung ist.

Zurück zur Titelfrage:

Erwägen Sie, table_open_cachewenn zu erhöhen

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

Wenn Sie es nicht erhöhen können, überprüfen Sie open_files_limitund das Betriebssystemlimit.

Wenn Ihr MySQL neu genug ist, stellen Sie table_open_cache_instances(vielleicht) die Anzahl der Kerne ein, die Sie haben.

Dies kann daran liegen, dass Ihre Anwendung möglicherweise dazu führt, dass MySQL tmp-Tabellen erstellt, wenn der Wert für Open_tables deutlich unter dem Wert für table_open_cache liegt. Durch das Erstellen von tmp-Tabellen wird auch der Opened_tables-Zähler erhöht. Ich führe auch das Mysqltuner-Skript aus und stelle fest, dass die Trefferquote im Tabellen-Cache unter 50% liegt. Ich habe mich gefragt, warum der verfügbare freie Cache-Speicherplatz nicht genutzt wird, aber die Anzahl steigt ständig. Das gleiche Buch, auf das Michael verweist, erklärt es. Hochleistungs-MySQL: Optimierung, Backups und Replikation

Es hängt davon ab, ob es Linux oder Windows ist.

Bei Windows mit Standardverbindung darf der Wert nicht größer als (2048-100) / 2 = 978 sein, da die Verbindung mit offener Tabelle x 2 + kleiner als 2048 sein muss. Ihre Windows-Ereignisanzeige zeigt an, ob Sie jemals eine falsche Konfiguration vorgenommen haben es.

Unter Linux kann der Wert viel höher sein, da das Dateideskriptorlimit viel höher ist. Sie können das Limit erhöhen, indem Sie es erhöhen ulimit.