Tips voor het leveren van MySQL-databaseprestaties - deel twee

Het beheer van databaseprestaties is een gebied waar beheerders vaak meer tijd aan besteden dan ze hadden verwacht.

Het bewaken van en reageren op prestatieproblemen met de productiedatabase is een van de meest kritieke taken binnen een databasebeheerderstaak. Het is een continu proces dat constante zorg vereist. Applicatie- en onderliggende databases evolueren meestal met de tijd; groeien in omvang, aantal gebruikers, werkdruk, schemawijzigingen die gepaard gaan met codewijzigingen.

Langlopende zoekopdrachten zijn zelden onvermijdelijk in een MySQL-database. In sommige omstandigheden kan een langlopende zoekopdracht een schadelijke gebeurtenis zijn. Als u om uw database geeft, moet u regelmatig de queryprestaties optimaliseren en langlopende query's detecteren.

In deze blog gaan we dieper in op de werkelijke database-werkbelasting, vooral aan de kant van de actieve query's. We zullen nagaan hoe we zoekopdrachten kunnen volgen, wat voor soort informatie we kunnen vinden in MySQL-metadata, welke tools we moeten gebruiken om dergelijke zoekopdrachten te analyseren.

De langlopende vragen afhandelen

Laten we beginnen met het controleren van Langlopende zoekopdrachten. Allereerst moeten we de aard van de query kennen, of het naar verwachting een langlopende of een kortlopende query is. Sommige analytische en batchbewerkingen zouden langlopende query's moeten zijn, dus die kunnen we voorlopig overslaan. Afhankelijk van de tabelgrootte kan het wijzigen van de tabelstructuur met de opdracht ALTER ook een langdurige operatie zijn (vooral in MySQL Galera Clusters).

• Tabelvergrendeling - De tabel wordt vergrendeld door een globale vergrendeling of expliciete tabelvergrendeling wanneer de query deze probeert te openen.
• Inefficiënte zoekopdracht - Gebruik niet-geïndexeerde kolommen tijdens het opzoeken of deelnemen, waardoor MySQL er langer over doet om aan de voorwaarde te voldoen.
• Deadlock - Er wacht een query om toegang te krijgen tot dezelfde rijen die zijn vergrendeld door een ander verzoek.
• Dataset past niet in RAM - Als de gegevens van uw werkset in die cache passen, zullen SELECT-query's meestal relatief snel zijn.
• Suboptimale hardwarebronnen - Dit kunnen trage schijven, RAID-reconstructie, verzadigd netwerk, enz. zijn.

Als je ziet dat het langer duurt dan normaal om een ​​zoekopdracht uit te voeren, onderzoek deze dan.

De MySQL Show Process List gebruiken

​MYSQL> SHOW PROCESSLIST;

Dit is meestal het eerste dat u uitvoert in het geval van prestatieproblemen. SHOW PROCESSLIST is een intern mysql-commando dat laat zien welke threads actief zijn. U kunt deze informatie ook bekijken in de tabel information_schema.PROCESSLIST of de opdracht mysqladmin process list. Als je het PROCES-privilege hebt, kun je alle threads zien. U kunt informatie zien zoals Query-ID, uitvoeringstijd, wie het uitvoert, de clienthost, enz. De informatie is enigszins op hun hoede, afhankelijk van de MySQL-smaak en -distributie (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 |

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

we kunnen de aanstootgevende zoekopdracht direct vanaf de uitvoer zien. In het bovenstaande voorbeeld zou dat een tafelvergrendeling kunnen zijn. Maar hoe vaak staren we naar die processen? Dit is alleen handig als u op de hoogte bent van de langlopende transactie. Anders zou je het pas weten als er iets gebeurt, zoals verbindingen die zich opstapelen of de server langzamer wordt dan normaal.

MySQL Pt-query-digest gebruiken

Als je meer informatie over een bepaalde werklast wilt zien, gebruik dan pt-query-digest. De pt-query-digest is een Linux-tool van Percona om MySQL-query's te analyseren. Het maakt deel uit van de Percona Toolkit die u hier kunt vinden. Het ondersteunt de meest populaire 64-bits Linux-distributies zoals Debian, Ubuntu en Redhat.

Om het te installeren, moet u Percona-repositories configureren en vervolgens het perona-toolkit-pakket installeren.

Installeer Percona Toolkit met uw pakketbeheerder:

Debian of Ubuntu:

sudo apt-get install percona-toolkit

RHEL of CentOS:

sudo yum install percona-toolkit

Pt-query-digest accepteert gegevens uit de proceslijst, algemeen logboek, binair logboek, langzame log of tcpdump Daarnaast is het mogelijk om de MySQL-proceslijst te pollen met een gedefinieerd interval - een proces die arbeidsintensief en verre van ideaal kan zijn, maar toch als alternatief kan worden gebruikt.

De meest voorkomende bron voor pt-query-digest is een langzame query-log. U kunt bepalen hoeveel gegevens daar naartoe gaan met parameter log_slow_verbosity.

Er zijn een aantal dingen die ervoor kunnen zorgen dat een query langer duurt om uit te voeren:

• microtime - zoekopdrachten met een precisie van microseconden.
• query_plan - informatie over het uitvoeringsplan van de query.
• innodb  - InnoDB-statistieken.
• minimaal - Gelijk aan het inschakelen van alleen microtime.
• standaard - Gelijk aan het inschakelen van microtime,innodb.
• full - Gelijk aan alle andere waarden OR'ed samen zonder de profilering en profiling_use_getrusage opties.
• profilering - Maakt profilering van alle zoekopdrachten in alle verbindingen mogelijk.
• profilering_use_getrusage - Maakt het gebruik van de getrusage-functie mogelijk.

bron:Percona-documentatie

Gebruik voor de volledigheid log_slow_verbosity=full, wat een veelvoorkomend geval is.

Langzaam zoekopdrachtlogboek

Het logbestand met trage zoekopdrachten kan worden gebruikt om zoekopdrachten te vinden die lang duren om uit te voeren en daarom in aanmerking komen voor optimalisatie. Logboek met trage query's legt langzame query's vast (SQL-instructies die meer dan long_query_time seconden nodig hebben om uit te voeren), of query's die geen indexen gebruiken voor zoekopdrachten (log_queries_not_using_indexes). Deze functie is standaard niet ingeschakeld en om deze in te schakelen, stelt u eenvoudig de volgende regels in en start u de MySQL-server opnieuw op:

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

Het logbestand met trage zoekopdrachten kan worden gebruikt om zoekopdrachten te vinden die lang duren om uit te voeren en daarom in aanmerking komen voor optimalisatie. Het onderzoeken van een lang traag querylogboek kan echter een tijdrovende taak zijn. Er zijn tools om MySQL-logbestanden voor langzame zoekopdrachten te ontleden en hun inhoud samen te vatten, zoals mysqldumpslow, pt-query-digest.

Prestatieschema

Prestatieschema is een geweldig hulpmiddel dat beschikbaar is voor het bewaken van de interne onderdelen en uitvoeringsdetails van MySQL Server op een lager niveau. Het had een slechte reputatie in een vroege versie (5.6) omdat het inschakelen ervan vaak prestatieproblemen veroorzaakte, maar de recente versies zijn niet schadelijk voor de prestaties. De volgende tabellen in Prestatieschema kunnen worden gebruikt om langzame zoekopdrachten te vinden:

• 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 en hoger bevatten het sys-schema, een set objecten waarmee DBA's en ontwikkelaars gegevens die door het prestatieschema zijn verzameld, kunnen interpreteren in een gemakkelijker te begrijpen vorm. Sys-schema-objecten kunnen worden gebruikt voor typische gevallen van afstemming en diagnose.

Netwerk volgen

Wat als we geen toegang hebben tot het querylogboek of directe toepassingslogboeken. In dat geval zouden we een combinatie van tcpdump en pt-query digest kunnen gebruiken die zou kunnen helpen bij het vastleggen van zoekopdrachten.

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

Zodra het opnameproces is afgelopen, kunnen we doorgaan met het verwerken van de gegevens:

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

ClusterControl-querymonitor

ClusterControl Query Monitor is een module in een clusterbesturing die gecombineerde informatie biedt over database-activiteit. Het kan informatie verzamelen uit meerdere bronnen, zoals de proceslijst weergeven of het logbestand met trage zoekopdrachten, en deze op een vooraf geaggregeerde manier presenteren.

De SQL-controle is verdeeld in drie secties.

Belangrijkste zoekopdrachten

presenteert de informatie over zoekopdrachten die een aanzienlijk deel van de bronnen vergen.

Zoekopdrachten uitvoeren

het is een proceslijst met informatie die is gecombineerd van alle databaseclusterknooppunten in één weergave. U kunt dat gebruiken om query's te beëindigen die uw databasebewerkingen beïnvloeden.

Uitschieters opvragen

presenteer de lijst met zoekopdrachten met een uitvoeringstijd die langer is dan gemiddeld.

Conclusie

Dit is allemaal voor deel twee. Deze blog is niet bedoeld als een uitputtende gids voor het verbeteren van de databaseprestaties, maar het geeft hopelijk een duidelijker beeld van wat essentieel kan worden en enkele van de basisparameters die kunnen worden geconfigureerd. Aarzel niet om ons te laten weten of we belangrijke hebben gemist in de onderstaande opmerkingen.