Tips til levering af MySQL-databaseydelse - Anden del

Styring af databaseydeevne er et område, som virksomheder, når administratorer ofte oplever, at de bidrager mere tid til, end de havde forventet.

Overvågning og reaktion på problemer med produktionsdatabasens ydeevne er en af ​​de mest kritiske opgaver i et databaseadministratorjob. Det er en løbende proces, der kræver konstant pleje. Applikation og underliggende databaser udvikler sig normalt med tiden; vokse i størrelse, antal brugere, arbejdsbyrde, skemaændringer, der følger med kodeændringer.

Langevarende forespørgsler er sjældent uundgåelige i en MySQL-database. I nogle tilfælde kan en langvarig forespørgsel være en skadelig begivenhed. Hvis du bekymrer dig om din database, skal optimering af forespørgselsydeevne og detektering af langvarige forespørgsler udføres regelmæssigt.

I denne blog vil vi tage et mere dybtgående kig på den faktiske databasearbejdsbelastning, især på den kørende forespørgselsside. Vi vil tjekke, hvordan man sporer forespørgsler, hvilken slags information vi kan finde i MySQL-metadata, hvilke værktøjer der skal bruges til at analysere sådanne forespørgsler.

Håndtering af langvarige forespørgsler

Lad os starte med at kontrollere langvarige forespørgsler. Først og fremmest skal vi kende arten af ​​forespørgslen, om det forventes at være en langvarig eller kort kørende forespørgsel. Nogle analytiske og batch-operationer formodes at være langvarige forespørgsler, så vi kan springe dem over indtil videre. Afhængigt af tabelstørrelsen kan ændring af tabelstrukturen med ALTER-kommandoen også være en langvarig operation (især i MySQL Galera Clusters).

• Tabellås – Tabellen er låst af en global lås eller eksplicit tabellås, når forespørgslen forsøger at få adgang til den.
• Ineffektiv forespørgsel - Brug ikke-indekserede kolonner, mens du slår op eller deltager, så MySQL tager længere tid at matche betingelsen.
• Deadlock - En forespørgsel venter på at få adgang til de samme rækker, som er låst af en anden anmodning.
• Datasæt passer ikke ind i RAM - Hvis dine arbejdssætdata passer ind i den cache, vil SELECT-forespørgsler normalt være relativt hurtige.
• Suboptimale hardwareressourcer - Dette kan være langsomme diske, RAID-genopbygning, mættet netværk osv.

Hvis du ser, at en forespørgsel tager længere tid end normalt at udføre, så undersøg den.

Brug af MySQL Show Process List

​MYSQL> SHOW PROCESSLIST;

Dette er normalt det første du kører i tilfælde af problemer med ydeevnen. SHOW PROCESSLIST er en intern mysql-kommando, som viser dig, hvilke tråde der kører. Du kan også se disse oplysninger fra informationsschema.PROCESSLIST-tabellen eller mysqladmin-proceslistekommandoen. Hvis du har PROCESS-privilegiet, kan du se alle tråde. Du kan se oplysninger som forespørgsels-id, eksekveringstid, hvem der kører den, klientværten osv. Oplysningerne er lidt forsigtige afhængigt af MySQL-smag og distribution (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 |

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

vi kan med det samme se den stødende forespørgsel med det samme fra outputtet. I ovenstående eksempel kunne det være en bordlås. Men hvor ofte stirrer vi på de processer? Dette er kun nyttigt, hvis du er opmærksom på den langvarige transaktion. Ellers ville du ikke vide det, før der sker noget - som at forbindelser hober sig op, eller serveren bliver langsommere end normalt.

Brug af MySQL Pt-query-digest

Hvis du gerne vil se mere information om en bestemt arbejdsbyrde, brug pt-query-digest. pt-query-digest er et Linux-værktøj fra Percona til at analysere MySQL-forespørgsler. Det er en del af Percona Toolkit, som du kan finde her. Det understøtter de mest populære 64 bit Linux-distributioner som Debian, Ubuntu og Redhat.

For at installere det skal du konfigurere Percona repositories og derefter installere perona-toolkit-pakken.

Installer Percona Toolkit ved hjælp af din pakkehåndtering:

Debian eller Ubuntu:

sudo apt-get install percona-toolkit

RHEL eller CentOS:

sudo yum install percona-toolkit

Pt-query-digest accepterer data fra proceslisten, generel log, binær log, langsom log eller tcpdump. Derudover er det muligt at polle MySQL proceslisten med et defineret interval - en proces der kan være ressourcekrævende og langt fra ideelt, men som stadig kan bruges som et alternativ.

Den mest almindelige kilde til pt-query-digest er en langsom forespørgselslog. Du kan kontrollere, hvor meget data der skal gå dertil med parameteren log_slow_verbosity.

Der er en række ting, der kan få en forespørgsel til at tage længere tid at udføre:

• mikrotid - forespørgsler med mikrosekunders præcision.
• query_plan - oplysninger om forespørgslens eksekveringsplan.
• innodb  - InnoDB-statistik.
• minimal – svarer til at aktivere mikrotid.
• standard - Svarer til at aktivere mikrotid,innodb.
• fuld – Svarer til alle andre værdier ELLER sammensat uden profilerings- og profiling_use_getrusage-mulighederne.
• profilering - Muliggør profilering af alle forespørgsler i alle forbindelser.
• profiling_use_getrusage - Aktiverer brug af getrusage-funktionen.

kilde:Percona-dokumentation

For fuldstændighedens skyld, brug log_slow_verbosity=full, som er et almindeligt tilfælde.

Langsom forespørgselslog

Den langsomme forespørgselslog kan bruges til at finde forespørgsler, der tager lang tid at udføre og derfor er kandidater til optimering. Langsom forespørgselslog fanger langsomme forespørgsler (SQL-sætninger, der tager mere end long_query_time sekunder at udføre), eller forespørgsler, der ikke bruger indekser til opslag (log_queries_not_using_indexes). Denne funktion er ikke aktiveret som standard, og for at aktivere den skal du blot indstille følgende linjer og genstarte MySQL-serveren:

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

Den langsomme forespørgselslog kan bruges til at finde forespørgsler, der tager lang tid at udføre og derfor er kandidater til optimering. Det kan dog være en tidskrævende opgave at undersøge en lang langsom forespørgselslog. Der er værktøjer til at parse MySQL langsomme forespørgselslogfiler og opsummere deres indhold som mysqldumpslow, pt-query-digest.

Ydeevneskema

Performance Schema er et fantastisk værktøj, der er tilgængeligt til at overvåge MySQL-serverens interne funktioner og udførelsesdetaljer på et lavere niveau. Det havde et dårligt ry i en tidlig version (5.6), fordi aktivering af det ofte forårsagede problemer med ydeevnen, men de seneste versioner skader ikke ydeevnen. Følgende tabeller i Performance Schema kan bruges til at finde langsomme forespørgsler:

• 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 og nyere inkluderer sys-skemaet, et sæt objekter, der hjælper DBA'er og udviklere med at fortolke data indsamlet af Performance Schema til en lettere forståelig form. Sys-skemaobjekter kan bruges til typiske tuning- og diagnosetilfælde.

Netværkssporing

Hvad hvis vi ikke har adgang til forespørgselsloggen eller direkte applikationslogfiler. I så fald kunne vi bruge en kombination af tcpdump og pt-query digest, som kunne hjælpe med at fange forespørgsler.

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

Når registreringsprocessen er afsluttet, kan vi fortsætte med at behandle dataene:

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

ClusterControl Query Monitor

ClusterControl Query Monitor er et modul i en klyngekontrol, der giver kombineret information om databaseaktivitet. Det kan indsamle oplysninger fra flere kilder som vis procesliste eller langsom forespørgselslog og præsentere det på en forud-aggregeret måde.

SQL-overvågningen er opdelt i tre sektioner.

Topforespørgsler

presenterer oplysningerne om forespørgsler, der kræver en betydelig del af ressourcerne.

Kører forespørgsler

det er en procesliste over information kombineret fra alle databaseklyndeknuder i én visning. Du kan bruge det til at dræbe forespørgsler, der påvirker dine databaseoperationer.

Forespørgsels-outliers

presenter listen over forespørgsler med udførelsestid længere end gennemsnittet.

Konklusion

Det hele er til del to. Denne blog er ikke beregnet til at være en udtømmende guide til, hvordan man forbedrer databasens ydeevne, men den giver forhåbentlig et klarere billede af, hvilke ting der kan blive væsentlige, og nogle af de grundlæggende parametre, der kan konfigureres. Tøv ikke med at fortælle os, hvis vi er gået glip af nogle vigtige i kommentarerne nedenfor.