it-swarm.com.de

MySQL table_cache und Opened_tables

Ich habe gesehen, dass Leute den Vergleich von Open_tables und Opened_tables verwenden, um festzustellen, ob der table_cache in MySQL zu klein ist. Ich glaube jedoch, dass Opened_tables über die Betriebszeit kumulativ ist, daher ist dies kein gültiger Vergleich. Die einzige Einschränkung ist, dass Opened_tables möglicherweise nur bei Fehlern auftritt - obwohl selbst wenn die pro Sekunde geöffneten Tabellen noch klein sind, es wahrscheinlich kein Problem ist, dass sie allmählich wachsen.

Wenn der Vergleich von Open_tables mit Opened_tables nicht gültig ist, gibt es eine andere Möglichkeit, Messdaten dafür zu erhalten?

Dies ist unter MySQL 5.0 möglich, aber auch Unterschiede zwischen den Versionen sind willkommen.

14
Sam Brightman

Der größte Grund für einen großen table_cache ist, dass LOCK_open mutex nicht heiß ist. MySQL vor 5.5 hat viele Konflikte, wenn Sie versuchen, Tabellen zu öffnen/schließen. Daher möchten Sie dies so weit wie möglich einschränken, d. H. Einen großen Tabellencache haben.

Sie interessieren sich also nicht für ein bestimmtes Verhältnis von Treffern zu Fehlschlägen (tatsächlich sollten Sie die Verhältnisse insgesamt ignorieren - dieser Blog-Beitrag erklärt, warum ). Was Sie interessiert, ist die Fehlerrate , denn je öfter dies pro Sekunde geschieht, desto höher ist die Wahrscheinlichkeit, dass Sie Konflikte haben (ein Thread muss) Warten Sie, bis ein anderer Thread die Sperre aufgehoben hat.)

Wie erkennen Sie die Miss Rate? Sie rufen während der geschäftigsten Zeit des Tages einige Beispiele von Opened_Tables im Abstand von einigen Sekunden ab. Wenn jedes Beispiel erhöht wird, ist es wahrscheinlich eine gute Idee, zu prüfen, ob Sie den table_cache erhöhen können.

Hinweis: Ich empfehle ausdrücklich nicht, mit der Betriebszeit zu vergleichen.

7
Morgan Tocker

Betrachten wir zunächst diese Statusvariablen:

Offene Tabellen : Die Anzahl der geöffneten Tabellen.

Opened_tables : Die Anzahl der geöffneten Tabellen. Wenn Opened_tables groß ist, ist Ihr table_open_cache-Wert wahrscheinlich zu klein.

Überraschenderweise liegt die Antwort auf Ihre Frage in der Frage selbst.

Die beiden Variablen wären nur dann sinnvoller, wenn Sie eine weitere Statusvariable in die Mischung einfügen: ptime (oder ptime_since_flush status für neue Durchschnittswerte nach FLUSH STATUS =).

Sie sollten Open_tables agsinst (Opened_tables/Uptime) vergleichen. Wenn Open_tables über (Opened_tables/Uptime) klettert, haben Sie jetzt Anlass zur Sorge und sollten ein Auge offen halten für Dinge wie die folgenden:

UPDATE 2011-08-31 12:18 EDT

Bitte beachten Sie, warum ich auch vorgeschlagen habe, Uptime_since_flush_status anstelle von Uptime zu verwenden, um eine zu erhalten Korrigieren Sie das Wachstumsmuster von Opened_tables für einen bestimmten Zeitraum.

Wenn Sie beispielsweise FLUSH STATUS; Jeden Montag um Mitternacht können Sie einen OpenTableFactor generieren:

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;

Dieser Faktor für offene Tabellen entspricht der Anzahl, die die Anzahl offener Tabellen zu einem bestimmten Zeitpunkt gegenüber der durchschnittlichen Anzahl geöffneter Tabellen während eines bestimmten Zeitraums darstellt. Mit einer FLUSH HOSTS; jede Woche/Tag/Host, dieser Durchschnitt ist gegen die Woche/Tag/Stunde.

Hier ist ein Beispiel von einem Kunden meines Arbeitgebers:

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)

Dieser Client verwaltet normalerweise ca. 7745 OpenTableFactor bei max. Wenn OpenTableFactor plötzlich (wenn auch nur geringfügig) abfällt, kann dies auf geringere Verkehrsmuster, stark abgebrochene Verbindungen usw. hinweisen. Wenn sich OpenTableFactor nie (wenn auch nur geringfügig) ändert, besteht möglicherweise die Möglichkeit, diese Einstellungen zu ändern:

Nach der Anpassung kann sich der OpenTableFactor ständig ändern oder eine andere Decke oder ein anderes Plateau erreichen. Daher ist die Verwendung verschiedener Einheiten innerhalb der Statusvariablen für diese Art der Abstimmung von entscheidender Bedeutung.

UPDATE 2011-08-31 12:42 EDT

Die SQL-Abfrage, die ich für OpenTableFactor ausgeführt habe, funktioniert nicht für MySQL 5.0 und zurück. Wenn Sie MySQL Administrator oder MONyog verwenden, können Sie ein Diagramm mithilfe der Formel in der Abfrage und im Monitor anpassen. MONyog sammelt den Verlauf mit SQLLite für spätere Verlaufsgrafiken. Dies kann für jede Version von MySQL durchgeführt werden.

5
RolandoMySQLDBA

Aus einem der Benutzerkommentare auf der Dokumentationsseite table_cache :

Opened_tables ist eine Statusvariable, die die Anzahl der zusätzlichen Dateideskriptoren, die zum Öffnen von Tabellen zu Zeiten zugewiesen wurden, zu denen die verfügbaren Dateideskriptoren in table_cache aufgebraucht wurden, laufend erfasst. ...

Dies bedeutet, dass es erhöht wird, wenn Sie Ihren table_cache - Wert überschreiten. Normalerweise überprüfe ich dies, indem ich opened_tables Mit uptime vergleiche, aber der Schlüssel hier ist, es über ein festgelegtes Intervall zu nehmen (zum Beispiel einmal pro Minute über zehn Minuten). Wenn es erhöht wird kann ein Hinweis darauf sein, dass Sie Ihren table_cache Erhöhen müssen.

Ein paar Vorsichtsmaßnahmen zu erwähnen:

  • Ein weiterer Kommentar in der obigen Dokumentation: "Die Statusvariable 'Opened_tables' wird jedes Mal, wenn Sie eine temporäre Tabelle erstellen, um 2 erhöht." Wenn Ihre Abfragen viele temporäre Tabellen erfordern, kann dies die Ursache für einen raschen Anstieg von opened_tables Sein. Sie können Ihre temporäre Tabellennutzung mithilfe der folgenden Abfrage anzeigen:

    SHOW GLOBAL STATUS LIKE '%tmp%';

  • Erhöhen Sie den table_cache nicht zu hoch hoch

    Der Grund für ein solches Verhalten ist, dass, wenn Sie große Nr. Haben. Bei Tabellen mit komplizierten Abfragen, die mehrere Tabellen verbinden, und mehreren Verbindungen, auf denen diese komplizierten Abfragen ausgeführt werden, wird möglicherweise der gesamte Cache Ihrer Dateideskriptoren (table_cache) verwendet. In diesem Fall verwendet MySQL einen Algorithmus, um den zuletzt verwendeten Deskriptor zu finden, ihn zu schließen und zu ersetzen es mit einem neuen Deskriptor.

3
Derek Downey