Suggerimenti per fornire prestazioni del database MySQL - Parte seconda

La gestione delle prestazioni del database è un'area in cui le aziende si trovano spesso a dedicare più tempo del previsto.

Il monitoraggio e la reazione ai problemi di prestazioni del database di produzione è una delle attività più critiche all'interno di un lavoro di amministratore di database. È un processo continuo che richiede cure costanti. L'applicazione e i database sottostanti di solito evolvono nel tempo; crescere in termini di dimensioni, numero di utenti, carico di lavoro, modifiche allo schema che derivano dalle modifiche al codice.

Le query di lunga durata sono raramente inevitabili in un database MySQL. In alcune circostanze, una query di lunga durata può essere un evento dannoso. Se ti interessa il tuo database, l'ottimizzazione delle prestazioni delle query e il rilevamento delle query con esecuzione prolungata devono essere eseguiti regolarmente.

In questo blog, daremo uno sguardo più approfondito al carico di lavoro effettivo del database, in particolare sul lato delle query in esecuzione. Verificheremo come tenere traccia delle query, che tipo di informazioni possiamo trovare nei metadati MySQL, quali strumenti utilizzare per analizzare tali query.

Gestire le query di lunga durata

Iniziamo con il controllo delle query di lunga durata. Prima di tutto, dobbiamo conoscere la natura della query, se si prevede che sia una query a esecuzione lunga o una query a esecuzione breve. Alcune operazioni analitiche e batch dovrebbero essere query di lunga durata, quindi per ora possiamo saltarle. Inoltre, a seconda delle dimensioni della tabella, la modifica della struttura della tabella con il comando ALTER può essere un'operazione di lunga durata (soprattutto nei cluster MySQL Galera).

• Blocco tabella:la tabella è bloccata da un blocco globale o da un blocco tabella esplicito quando la query tenta di accedervi.
• Query inefficiente:utilizza colonne non indicizzate durante la ricerca o l'unione, quindi MySQL impiega più tempo per soddisfare la condizione.
• Deadlock:una query è in attesa di accedere alle stesse righe bloccate da un'altra richiesta.
• Il set di dati non si adatta alla RAM - Se i dati del tuo set di lavoro rientrano in quella cache, le query SELECT saranno generalmente relativamente veloci.
• Risorse hardware non ottimali:potrebbero essere dischi lenti, ricostruzione RAID, rete satura, ecc.

Se vedi che una query impiega più tempo del solito per essere eseguita, esaminala.

Utilizzo dell'elenco dei processi di visualizzazione MySQL

​MYSQL> SHOW PROCESSLIST;

Questa è solitamente la prima cosa che esegui in caso di problemi di prestazioni. SHOW PROCESSLIST è un comando mysql interno che mostra quali thread sono in esecuzione. Puoi anche vedere queste informazioni dalla tabella information_schema.PROCESSLIST o dal comando mysqladmin process list. Se hai il privilegio PROCESSO, puoi vedere tutti i thread. Puoi vedere informazioni come ID query, tempo di esecuzione, chi lo esegue, l'host del client, ecc. Le informazioni sono leggermente caute a seconda del sapore e della distribuzione di MySQL (Oracle, MariaDB, Percona)

SHOW PROCESSLIST;

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

| Id | User            | Host | db | Command | Time | State                  | Info | Progress |

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

|  2 | event_scheduler | localhost | NULL | Daemon  | 2693 | Waiting on empty queue | NULL   | 0.000 |

|  4 | root            | localhost | NULL | Query   | 0 | Table lock   | SHOW PROCESSLIST | 0.000 |

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

possiamo vedere immediatamente la query offensiva subito dall'output. Nell'esempio sopra potrebbe essere un blocco tabella. Ma quante volte fissiamo quei processi? Questo è utile solo se sei a conoscenza della transazione di lunga durata. Altrimenti, non lo sapresti fino a quando non succede qualcosa, ad esempio le connessioni si stanno accumulando o il server sta diventando più lento del solito.

Utilizzo di MySQL Pt-query-digest

Se desideri visualizzare maggiori informazioni su un particolare carico di lavoro, usa pt-query-digest. pt-query-digest è uno strumento Linux di Percona per analizzare le query MySQL. Fa parte del Percona Toolkit che puoi trovare qui. Supporta le distribuzioni Linux a 64 bit più popolari come Debian, Ubuntu e Redhat.

Per installarlo devi configurare i repository Percona e quindi installare il pacchetto perona-toolkit.

Installa Percona Toolkit utilizzando il tuo gestore di pacchetti:

Debian o Ubuntu:

sudo apt-get install percona-toolkit

RHEL o CentOS:

sudo yum install percona-toolkit

Pt-query-digest accetta i dati dall'elenco dei processi, dal registro generale, dal registro binario, dal registro lento o da tcpdump Inoltre, è possibile eseguire il polling dell'elenco dei processi MySQL a un intervallo definito:un processo che può essere dispendioso in termini di risorse e tutt'altro che ideale, ma può comunque essere utilizzato come alternativa.

La fonte più comune per pt-query-digest è un log di query lento. Puoi controllare la quantità di dati che andrà lì con il parametro log_slow_verbosity.

Ci sono un certo numero di cose che possono far sì che una query richieda più tempo per l'esecuzione:

• microtime:query con precisione al microsecondo.
• query_plan - informazioni sul piano di esecuzione della query.
• innodb  - Statistiche di InnoDB.
• minimo - Equivale a abilitare solo il microtempo.
• standard:equivalente all'abilitazione di microtime,innodb.
• completo:equivalente a tutti gli altri valori riuniti in OR senza le opzioni di profilazione e profilazione_use_getrusage.
• profilazione:consente la profilatura di tutte le query in tutte le connessioni.
• profiling_use_getrusage - Abilita l'utilizzo della funzione getrusage.

fonte:documentazione Percona

Per completezza usa log_slow_verbosity=full che è un caso comune.

Registro query lento

Il log delle query lente può essere utilizzato per trovare query che richiedono molto tempo per essere eseguite e sono quindi candidate per l'ottimizzazione. Il registro delle query lente acquisisce query lente (istruzioni SQL che richiedono più di long_query_time secondi per l'esecuzione) o query che non utilizzano indici per le ricerche (log_queries_not_using_indexes). Questa funzionalità non è abilitata per impostazione predefinita e per abilitarla è sufficiente impostare le seguenti righe e riavviare il server MySQL:

[mysqld]
slow_query_log=1
log_queries_not_using_indexes=1
long_query_time=0.1

Il log delle query lente può essere utilizzato per trovare query che richiedono molto tempo per essere eseguite e sono quindi candidate per l'ottimizzazione. Tuttavia, l'esame di un log di query lungo e lento può richiedere molto tempo. Esistono strumenti per analizzare i file di registro delle query lente di MySQL e riassumerne il contenuto come mysqldumpslow, pt-query-digest.

Schema delle prestazioni

Lo schema delle prestazioni è un ottimo strumento disponibile per il monitoraggio degli interni di MySQL Server e dei dettagli di esecuzione a un livello inferiore. Aveva una cattiva reputazione in una versione precedente (5.6) perché abilitarlo spesso causava problemi di prestazioni, tuttavia le versioni recenti non danneggiano le prestazioni. Le seguenti tabelle in Performance Schema possono essere utilizzate per trovare query lente:

• events_statements_current
• events_statements_history
• events_statements_history_long
• events_statements_summary_by_digest
• events_statements_summary_by_user_by_event_name
• events_statements_summary_by_host_by_event_name

MySQL 5.7.7 e versioni successive includono lo schema sys, un insieme di oggetti che aiuta i DBA e gli sviluppatori a interpretare i dati raccolti dallo schema delle prestazioni in una forma più facilmente comprensibile. Gli oggetti Sys schema possono essere utilizzati per i tipici casi d'uso di ottimizzazione e diagnosi.

Tracciamento della rete

Cosa succede se non abbiamo accesso al registro delle query o ai registri dell'applicazione diretta. In tal caso, potremmo utilizzare una combinazione di tcpdump e pt-query digest che potrebbe aiutare a catturare le query.

$ tcpdump -s 65535 -x -nn -q -tttt -i any port 3306 > mysql.tcp.txt

Una volta terminato il processo di acquisizione, possiamo procedere con l'elaborazione dei dati:

$ pt-query-digest --limit=100% --type tcpdump mysql.tcp.txt > ptqd_tcp.out

Monitoraggio query ClusterControl

ClusterControl Query Monitor è un modulo in un controllo cluster che fornisce informazioni combinate sull'attività del database. Può raccogliere informazioni da più fonti come mostra l'elenco dei processi o il registro delle query lente e presentarle in modo preaggregato.

Il monitoraggio SQL è diviso in tre sezioni.

Ricerche principali

presenta le informazioni sulle query che richiedono una parte significativa di risorse.

Query in esecuzione

è un elenco di processi di informazioni combinate da tutti i nodi del cluster di database in un'unica vista. Puoi usarlo per terminare le query che influiscono sulle operazioni del tuo database.

Query valori anomali

presenta l'elenco delle query con un tempo di esecuzione superiore alla media.

Conclusione

Questo è tutto per la seconda parte. Questo blog non vuole essere una guida esauriente su come migliorare le prestazioni del database, ma si spera fornisca un quadro più chiaro di ciò che può diventare essenziale e di alcuni parametri di base che possono essere configurati. Non esitare a farci sapere se abbiamo perso qualcosa di importante nei commenti qui sotto.