it-swarm.it

MySQL table_cache e Opened_tables

Ho visto persone usare il confronto di Open_tables e Opened_tables per valutare se table_cache è troppo piccolo in MySQL. Tuttavia, ritengo che Opened_tables sia cumulativo nel tempo di attività, quindi questo non è un confronto valido. L'unico avvertimento è che forse Opened_tables è solo un errore, anche se anche se i tavoli che vengono aperti al secondo sono ancora piccoli, probabilmente non è un problema che cresca gradualmente.

Se il confronto tra Open_tables e Opened_tables non è valido, esiste un altro modo per ottenere i dati misurati per questo?

Questo è su MySQL 5.0, ma anche le differenze tra le versioni sono benvenute.

14
Sam Brightman

Il motivo principale per avere un table_cache di grandi dimensioni è che LOCK_open mutex non è caldo. MySQL precedente alla 5.5 presenta molte controversie quando si tenta di aprire/chiudere le tabelle, quindi si desidera limitare il più possibile questa operazione, ovvero disporre di una cache di tabelle di grandi dimensioni.

Quindi non ti interessa un particolare rapporto tra hit e miss (infatti dovresti ignorare del tutto i rapporti - questo post sul blog spiega perché ). Quello che ti interessa è il tasso di mancato guadagno , perché più volte questo accade al secondo, maggiore è la possibilità che tu abbia contesa (un thread deve attendere che un altro thread rilasci il blocco.)

Come si individua la percentuale di miss? Prendi alcuni campioni di Opened_Tables a pochi secondi di distanza durante il periodo più trafficato della giornata, e se ci sono aumenti in ciascun campione, è probabilmente una buona idea vedere se riesci ad aumentare il table_cache.

Nota: in particolare, non consiglio di confrontare i tempi di attività.

7
Morgan Tocker

Innanzitutto, consideriamo quelle variabili di stato:

Apri tabelle : il numero di tabelle aperte.

Opened_tables : il numero di tabelle che sono state aperte. Se Opened_tables è grande, il valore di table_open_cache è probabilmente troppo piccolo.

Sorprendentemente, la risposta alla tua domanda sta nella domanda stessa.

Le due variabili avrebbero più senso se si gettasse un'altra variabile di stato nel mix: ptime (o ptime_since_flush status per medie fresche dopo STATO FLUSH =).

Dovresti confrontare Open_tables agsinst (Opened_tables/Uptime) . Se Open_tables sale sopra (Opened_tables/Uptime) , ora hai motivo di preoccupazione e dovresti tenere d'occhio cose come le seguenti:

AGGIORNAMENTO 2011-08-31 12:18 EDT

Nota perché ho anche suggerito di utilizzare Uptime_since_flush_status anziché Uptime per ottenere un correggi il modello di crescita Opened_tables per un determinato periodo.

Ad esempio, se si esegue FLUSH STATUS; ogni lunedì a mezzanotte, puoi generare un 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;

Questo fattore di tabella aperta equivale al numero che rappresenta il numero di tabelle aperte in un dato momento rispetto al numero medio di tabelle aperte durante un determinato periodo. Con un FLUSH HOSTS; ogni settimana/giorno/host, tale media è in contrasto con la settimana/giorno/ora.

Ecco un esempio di uno dei clienti del mio datore di lavoro:

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)

Questo client mantiene normalmente circa 7745 OpenTableFactor al massimo. Se OpenTableFactor si abbassa improvvisamente (anche se un po '), potrebbe indicare modelli di traffico più bassi, alte concentrazioni interrotte e così via. Se OpenTableFactor non cambia mai (anche se un po '), potrebbe offrirti l'opportunità di modificare queste impostazioni:

Una volta regolato, OpenTableFactor può cambiare costantemente o colpire un altro soffitto o plateau. Pertanto, l'utilizzo di unità diverse all'interno delle variabili di stato diventa vitale per questo tipo di ottimizzazione.

AGGIORNAMENTO 2011-08-31 12:42 EDT

La query SQL che ho eseguito per OpenTableFactor non funziona per MySQL 5.0 e versioni successive. Se stai usando MySQL Administrator o MONyog , puoi personalizzare un grafico usando la formula nella query e nel monitor. MONyog raccoglie la cronologia usando SQLLite per la successiva rappresentazione grafica storica. Questo può essere fatto per qualsiasi versione di MySQL.

5
RolandoMySQLDBA

Da uno dei commenti dell'utente nella pagina di documentazione table_cache :

Opened_tables è una variabile di stato che mantiene un conteggio corrente del numero di descrittori di file aggiuntivi che sono stati allocati per l'apertura di tabelle a volte in cui i descrittori di file disponibili in table_cache sono stati esauriti. ...

Ciò significa che viene incrementato quando passi sopra il tuo table_cache valore. Quindi il modo in cui lo controllo normalmente è confrontare opened_tables con uptime, ma la chiave qui è di prenderlo per un intervallo prestabilito (una volta al minuto per dieci minuti, ad esempio). Se lo aumenta può essere un'indicazione che devi aumentare il tuo table_cache.

Un paio di avvertimenti per menzionare:

  • Un altro commento nella suddetta documentazione: "Anche la variabile di stato 'Opened_tables' verrà incrementata di 2 ogni volta che crei una tabella temporanea." Pertanto, se le tue query richiedono molte tabelle temporanee, questa potrebbe essere la causa di un rapido aumento di opened_tables. È possibile visualizzare l'utilizzo temporaneo della tabella utilizzando la seguente query:

    SHOW GLOBAL STATUS LIKE '%tmp%';

  • Non aumentare troppo table_cache alto

    La ragione di tale comportamento è che, se si dispone di un grande no. di tabelle con query complicate che uniscono più tabelle e connessioni multiple che eseguono quelle query complicate, si potrebbe finire per utilizzare la cache di tutti i descrittori di file (table_cache) in tal caso MySQL utilizza un algoritmo per trovare il descrittore utilizzato più di recente, chiuderlo e sostituirlo con un nuovo descrittore.

3
Derek Downey