Mysql
 sql >> Database >  >> RDS >> Mysql

Monitoraggio efficace di MySQL con i dashboard SCUMM:parte 3

Abbiamo discusso nei nostri blog precedenti delle dashboard relative a MySQL. Abbiamo evidenziato le cose di cui un DBA può trarre vantaggio dallo studio dei grafici, soprattutto quando esegue le proprie routine quotidiane dalla diagnostica, dal reporting delle metriche e dalla pianificazione della capacità. In questo blog discuteremo delle metriche InnoDB e dello schema delle prestazioni MySQL, che è molto importante soprattutto per il monitoraggio delle transazioni InnoDB, dell'I/O disco/cpu/memoria, dell'ottimizzazione delle query o dell'ottimizzazione delle prestazioni del server.

Questo blog tocca l'argomento profondo delle prestazioni, considerando che InnoDB richiederebbe un'ampia copertura se affrontiamo i suoi interni. Anche lo schema delle prestazioni è ampio in quanto copre kernel e parti principali di MySQL e motori di archiviazione.

Iniziamo a scorrere i grafici.

Metriche MySQL InnoDB

Questa dashboard è ottima per qualsiasi DBA MySQL o persona operativa, in quanto offre un'ottima visuale del motore di archiviazione InnoDB. Ci sono alcuni grafici qui che un utente deve considerare per abilitare, perché non in tutte le situazioni le variabili sono impostate correttamente nella configurazione di MySQL.

  • Età del checkpoint di Innodb

    Secondo il manuale, il checkpoint è definito come segue:"Quando vengono apportate modifiche alle pagine di dati memorizzate nella cache nel pool di buffer , tali modifiche vengono scritte nei file di dati qualche tempo dopo, un processo noto come lavaggio . Il checkpoint è una registrazione delle ultime modifiche (rappresentate da un LSN value) che sono stati scritti correttamente nei file di dati ”. Questo grafico è utile quando si desidera determinare in che modo il server esegue il checkpoint dei dati sul disco. Questo può essere un buon riferimento se il registro delle transazioni (registro di ripristino o ib_logfile0) è troppo grande. Questo grafico è anche un buon indicatore se è necessario regolare variabili come innodb_log_file_size, innodb_log_buffer_size, innodb_max_dirty_pages_pct o innodb_adaptive_flushing_method. Più l'età del checkpoint si avvicina all'età massima del checkpoint, più i log sono pieni e InnoDB eseguirà più I/O per mantenere un po' di spazio libero nei log. Il meccanismo di checkpoint differisce nei minimi dettagli tra le versioni basate su Percona XtraDB, MariaDB e Oracle, puoi anche trovare differenze nella sua implementazione tra le versioni di MySQL.

  • Transazioni InnoDB

    Ogni volta che c'è una grande transazione in corso nel tuo server MySQL, questo grafico è un buon riferimento. Conterà le transazioni che sono state create in un momento specifico e la lunghezza della cronologia (o è effettivamente la lunghezza dell'elenco della cronologia trovata in SHOW ENGINE INNODB STATUS) è ​​il numero di pagine nel registro di annullamento. Le tendenze che vedrai qui sono una buona risorsa per verificare se potrebbe significare, ad esempio, che l'eliminazione è ritardata a causa di una velocità di inserimento molto elevata del ricaricamento dei dati o a causa di una transazione di lunga durata, o se l'eliminazione può semplicemente non tiene il passo a causa di un I/O del disco elevato nel volume in cui risiede $DATADIR.

  • Operazioni Innodb Row

    Per alcune attività DBA, potresti voler determinare il numero di eliminazioni, inserimenti, letture e righe aggiornate. Quindi questo grafico è ciò che puoi utilizzare per verificarli.

  • Tempo di blocco riga di Innodb

    Questo grafico è una buona risorsa da considerare quando si nota che l'applicazione sta riscontrando molte occorrenze per “Timeout di attesa del blocco superato; prova a riavviare la transazione ”. Questo può anche aiutarti a determinare se potresti avere un'indicazione per l'utilizzo di query errate sulla gestione dei blocchi. Questo è anche un buon riferimento da considerare quando si ottimizzano le query che comportano il blocco delle righe. Se il tempo di attesa è troppo lungo, è necessario controllare il log delle query lente o eseguire un pt-query-digest e vedere quali sono le query sospette che causano quel rigonfiamento nel grafico.

  • I/O InnoDB

    Ogni volta che vuoi determinare la quantità di letture di dati InnoDB, svuotamenti del disco, scritture e scritture di log, questo grafico ha ciò che devi guardare. Puoi utilizzare questo grafico per determinare se le tue variabili InnoDB sono ben sintonizzate per gestire i tuoi requisiti specifici. Ad esempio, se hai la cache del modulo di backup della batteria ma non stai ottenendo molte delle sue prestazioni ottimali, puoi fare affidamento su questo grafico per determinare se i tuoi fsyncs() sono superiori al previsto. Quindi la modifica della variabile innodb_flush_method e l'utilizzo di O_DSYNC possono risolvere il problema.

  • Utilizzo del file di registro InnoDB ogni ora

    Questo grafico mostra solo il numero di byte scritti nei file di registro di ripristino di InnoDB e la crescita dei file di registro di InnoDB in base all'intervallo di tempo di 24 ore della data corrente.

  • Prestazioni di registrazione InnoDB

    Questo grafico è strettamente correlato al grafico orario di utilizzo del file di registro di InnoDB. Devi usare questo grafico ogni volta che devi determinare quanto grande deve essere il tuo innodb_log_file_size. È possibile determinare il numero di byte scritti nei file di registro di ripristino di InnoDB e l'efficienza con cui MySQL scarica i dati dalla memoria al disco. Ogni volta che hai bisogno di poco tempo per usare il tuo spazio di log di ripristino, indicherebbe che devi aumentare la dimensione del tuo innodb_log_file. In tal caso, questo grafico ti direbbe che devi farlo. Tuttavia, per approfondire la quantità di cui hai bisogno per il tuo innodb_log_file, potrebbe avere più senso controllare l'LSN (Log Sequence Number) in SHOW ENGINE INNODB STATUS. Percona ha un buon blog relativo a questo che è una buona fonte da guardare.

  • Deadlock di InnoDB

    In alcune situazioni in cui il tuo client dell'applicazione sta riscontrando spesso deadlock o devi guardare quanto il tuo MySQL sta vivendo deadlock, questo grafico serve allo scopo. I deadlock indicano che hai una progettazione SQL scadente che porta le tue transazioni a creare una race condition che causa deadlock.

  • Pushdown della condizione dell'indice

    Una piccola parola di cautela quando si guarda questo grafico. Innanzitutto, devi determinare che la tua variabile globale MySQL innodb_monitor_enable è impostata sul valore corretto che è module_icp. In caso contrario, riscontrerai un "Nessun punto dati" come mostrato di seguito:

    Lo scopo del grafico, se ha punti dati definiti come quelli che ho negli output di esempio, fornirà a un DBA una panoramica di quanto bene le tue query stiano beneficiando con Index Condition Pushdown o ICP in breve. ICP è un'ottima funzionalità in MySQL che offre l'ottimizzazione delle tue query. Invece di leggere le righe complete filtrate nelle tue query WHERE al momento del recupero, MySQL aggiungerà più controlli dopo i tuoi indici secondari. Ciò aggiunge maggiore granularità e consente di risparmiare tempo, altrimenti il ​​motore deve leggere le righe della tabella completa quando si basa solo sull'indice filtrato e non viene utilizzato ICP. Questo evita di leggere le righe complete corrispondenti alle tue tuple di indice che corrispondono ai tuoi indici secondari.

    Consentitemi di elaborare un po' questo grafico, diciamo che ho una tabella denominata:

    mysql> show create table a\G
*************************** 1. row ***************************
       Table: a
Create Table: CREATE TABLE `a` (
  `id` int(11) NOT NULL,
  `age` int(11) NOT NULL,
  KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

    E ha alcuni piccoli dati:

    mysql> select * from a;
+----+-----+
| id | age |
+----+-----+
|  1 |   1 |
|  2 |   1 |
|  3 |   1 |
|  3 |  41 |
|  4 |  41 |
|  5 |   4 |
|  4 |   4 |
|  4 |   4 |
+----+-----+
8 rows in set (0.00 sec)

    Quando ICP è abilitato, i risultati sono più efficienti e fattibili:

    mysql> explain extended select * from a where id>2 and id<4 and age=41;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra                              |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
|  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using index condition; Using where |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
1 row in set, 2 warnings (0.00 sec)

    Che senza ICP,

    mysql> set optimizer_switch='index_condition_pushdown=off';
Query OK, 0 rows affected (0.00 sec)

mysql> explain extended select * from a where id>2 and id<4 and age=41;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using where |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 2 warnings (0.00 sec)

    Questo è un semplice esempio di ICP e di come questo grafico può avvantaggiare un DBA.

  • Contenuto del pool di buffer InnoDB

    Quando si lavora con MySQL e si utilizza il motore InnoDB, questo grafico è uno dei valori più comuni (innodb_buffer_pool*) che è necessario ottimizzare per ottimizzare le prestazioni di MySQL. Parlando in particolare del contenuto del pool di buffer, visualizza le tendenze per le pagine sporche rispetto al contenuto del pool di buffer totale. Il contenuto totale del pool di buffer include le pagine pulite a parte le pagine sporche. Determinando l'efficienza con cui MySQL gestisce il pool di buffer, questo grafico serve al suo scopo.

  • Pagine del pool di buffer InnoDB

    Questo grafico è utile quando si desidera verificare l'efficienza di MySQL utilizzando il pool di buffer InnoDB. Puoi utilizzare questo grafico, ad esempio, se il tuo traffico giornaliero non riempie l'innodb_buffer_pool_size assegnato, questo potrebbe indicare che alcune parti di un'applicazione non sono utili o non servono a nessuno scopo o se imposti innodb_buffer_pool_size molto alto che potrebbe essere utile per abbassare il valore e recuperare spazio nella tua memoria.

  • I/O pool di buffer InnoDB

    Quando devi controllare il numero di pagine create e scritte sulle tabelle InnoDB o le pagine lette nel pool di buffer InnoDB mediante operazioni sulle tabelle InnoDB.

  • Richieste di pool di buffer InnoDB

    Quando vuoi determinare l'efficienza con cui le tue query accedono al pool di buffer InnoDB, questo grafico serve allo scopo. Questo grafico mostrerà le tendenze in base ai punti dati su come si comporta il tuo server MySQL quando il motore InnoDB deve accedere frequentemente al disco (l'indicazione del pool di buffer non si è ancora riscaldata), la frequenza con cui le richieste del pool di buffer gestivano richieste di lettura e scrittura richieste.

  • InnoDB Read-Ahead

    Quando hai la variabile innodb_random_read_ahead impostata su ON, aggiungi questo grafico come una tendenza preziosa da considerare come parte della tua routine DBA. Mostra le tendenze su come il tuo motore di archiviazione MySQL InnoDB gestisce il pool di buffer tramite il thread in background read-ahead, come gestisce quelli successivamente eliminati senza che le query abbiano avuto accesso e come InnoDB avvia il read-ahead casuale quando una query esegue la scansione una grande porzione di una tabella ma in ordine casuale.

  • Buffer di modifiche InnoDB

    Quando Percona Server 5.7 è in esecuzione, questo grafico è utile per monitorare quanto bene InnoDB ha allocato il buffer delle modifiche. Queste modifiche includono quegli inserimenti, aggiornamenti ed eliminazioni specificati dalla variabile innodb_change_buffering. Il buffering delle modifiche aiuta a velocizzare le query, evitando sostanziali I/O ad accesso casuale che sarebbero necessari per leggere le pagine di indice secondarie dal disco.

  • Attività del buffer di modifica di InnoDB

    Questo è correlato al grafico InnoDB Change Buffer, ma seziona le informazioni in punti dati più praticabili. Questi forniscono ulteriori informazioni per monitorare come InnoDB gestisce il buffering delle modifiche. Ciò è utile in una particolare attività DBA per determinare se innodb_change_buffer_max_size è impostato su un valore troppo alto, poiché il buffering delle modifiche condivide la stessa memoria del pool di buffer InnoDB riducendo la memoria disponibile per memorizzare nella cache le pagine di dati. Potrebbe essere necessario considerare di disabilitare il buffering delle modifiche se il working set si adatta quasi al pool di buffer o se le tabelle hanno relativamente pochi indici secondari. Ricorda che il buffering delle modifiche non impone un sovraccarico aggiuntivo, perché si applica solo alle pagine che non si trovano nel pool di buffer. Questo grafico è utile anche se devi determinare in che modo le unioni sono utili se devi confrontare la tua applicazione in base a determinate richieste per scenari particolari. Supponiamo che tu abbia un inserimento in blocco, devi impostare innodb_change_buffering=insert e determinare se avere i valori impostati nel pool di buffer e innodb_change_buffer_max_size non influiscono sull'I/O del disco, specialmente durante il ripristino o lo spegnimento lento (necessario se si desidera eseguire un failover con bassi tempi di inattività). Inoltre, questo grafico può servire allo scopo di valutare determinati scenari, poiché l'unione del buffer delle modifiche può richiedere diverse ore quando sono presenti numerosi indici secondari da aggiornare e molte righe interessate. Durante questo periodo, l'I/O del disco viene aumentato, il che può causare un rallentamento significativo per le query associate al disco.

Schema delle prestazioni MySQL

Il MySQL Performance Schema è un argomento complicato. È lungo e difficile, ma discuterò solo le informazioni specifiche dei grafici che abbiamo in SCUMM. Ci sono anche alcune variabili che devi considerare e assicurarti che siano impostate correttamente. Assicurati di avere la tua variabile innodb_monitor_enable =all e userstat=1 per vedere i punti dati nei tuoi grafici. Come nota, quando sto usando la parola "evento" qui, non significa che questo sia correlato a MySQL Event Scheduler. Sto parlando di eventi specifici come MySQL analizza una query, MySQL sta leggendo o scrivendo in un file di registro di inoltro/binario, ecc.

Procediamo allora con i grafici.

  • I/O del file dello schema delle prestazioni (eventi)

    Questo grafico recupera i punti dati relativi a qualsiasi evento verificatosi in MySQL che potrebbe essere stato strumentato per creare più istanze dell'oggetto strumentato (ad es. letture di log binari o letture di file di dati InnoDB). Ogni riga riassume gli eventi per un determinato nome di evento. Ad esempio, se è presente uno strumento per un mutex creato per ciascuna connessione, potrebbero esserci molte istanze di questo evento instrumentato poiché esistono più connessioni. La riga di riepilogo per lo strumento riassume tutte queste istanze. Puoi controllare questi eventi nel manuale MySQL per le tabelle di riepilogo dello schema delle prestazioni per ulteriori informazioni.

  • I/O (caricamento) del file dello schema delle prestazioni

    Questo grafico è uguale al grafico "Performance Schema File IO (Events)", tranne per il fatto che è strumentato in base al carico.

  • I/O del file dello schema delle prestazioni (byte)

    Questo grafico è uguale al grafico "Performance Schema File IO (Events)" tranne per il fatto che è strumentato in base alla dimensione in byte. Ad esempio, quanto tempo ha impiegato un evento specifico quando MySQL ha attivato l'evento wait/io/file/innodb/innodb_data_file.

  • Attese dello schema di prestazioni (eventi)

    Questo grafico contiene il grafico dei dati per tutte le attese spese per un evento specifico. Puoi controllare le tabelle di riepilogo degli eventi di attesa nel manuale per ulteriori informazioni.

  • Attese dello schema di prestazioni (carico)

    Uguale al grafico "Performance Schema Waits (Events)", ma questa volta mostra le tendenze per il carico.

  • Operazioni di accesso all'indice (caricamento)

    Questo grafico è un'aggregazione di tutti gli eventi di attesa I/O dell'indice della tabella raggruppati per indice(i) di una tabella, come generato dallo strumento wait/io/table/sql/handler. Puoi controllare il manuale MySQL sulla tabella dello schema delle prestazioni table_io_waits_summary_by_index_usage per maggiori informazioni.

  • Operazioni di accesso alla tabella (caricamento)

    Il grafico "Come Index Access Operations (Load)", è un'aggregazione di tutti gli eventi di attesa di I/O tabella raggruppati per tabella, come generato dallo strumento wait/io/table/sql/handler. Questo è molto utile per i DBA. Ad esempio, si desidera tracciare la velocità necessaria per accedere (recuperare) o aggiornare (inserire, eliminare, aggiornare) una tabella specifica. Puoi controllare nel manuale MySQL sulla tabella dello schema delle prestazioni table_io_waits_summary_by_table per maggiori informazioni.

  • Schema delle prestazioni SQL e blocchi esterni (eventi)

    Questo grafico è un'aggregazione (conta quante volte si è verificato) di tutti gli eventi di attesa del blocco della tabella, generati dallo strumento wait/lock/table/sql/handler che è raggruppato per tabella. Il blocco SQL qui nel grafico indica i blocchi interni. Questi blocchi interni vengono letti normalmente, letti con blocchi condivisi, letti con priorità alta, non letti senza inserimento, scrittura consentiti, scrittura con inserimento simultaneo, scrittura ritardata, scrittura con priorità bassa, scrittura normale. Mentre i blocchi esterni vengono letti esterni e scrivono esterni. In qualsiasi attività DBA, questo è molto utile se devi tracciare ed esaminare i blocchi su una determinata tabella indipendentemente dal suo tipo. Puoi controllare la tabella table_lock_waits_summary_by_table per maggiori informazioni.

  • Schema delle prestazioni SQL e blocchi esterni (secondi)

    Uguale al grafico "Performance Schema SQL &External Locks (Events)", ma specificato in secondi. Se vuoi cercare i blocchi della tabella in base ai secondi in cui ha tenuto i blocchi, allora questo grafico è la tua buona risorsa.

Conclusione

Le metriche InnoDB e lo schema delle prestazioni MySQL sono alcune delle parti più approfondite e complicate del dominio MySQL, specialmente quando non c'è visualizzazione per assistere l'interpretazione. Pertanto, passare a una traccia manuale e alle indagini potrebbe richiedere parte del tuo tempo e del tuo duro lavoro. I dashboard SCUMM offrono un modo molto efficiente e fattibile per gestirli e ridurre il carico aggiuntivo su qualsiasi attività di routine DBA.

In questo blog hai imparato come utilizzare i dashboard per InnoDB e Performance Schema per migliorare le prestazioni del database. Questi dashboard possono renderti più efficiente nell'analisi delle prestazioni.