Omgaan met MySQL langlopende zoekopdrachten

Langlopende queries/statements/transacties zijn soms onvermijdelijk in een MySQL-omgeving. In sommige gevallen kan een langlopende zoekopdracht een katalysator zijn voor een rampzalige gebeurtenis. Als u om uw database geeft, moet u regelmatig de queryprestaties optimaliseren en langlopende query's detecteren. Het wordt echter moeilijker als er meerdere instanties in een groep of cluster bij betrokken zijn.

Als we met meerdere knooppunten te maken hebben, moeten we de repetitieve taken om elk knooppunt te controleren, vermijden. ClusterControl bewaakt meerdere aspecten van uw databaseserver, inclusief query's. ClusterControl verzamelt alle query-gerelateerde informatie van alle knooppunten in de groep of cluster om een gecentraliseerde weergave van de werkbelasting te bieden. Er is een geweldige manier om uw cluster als geheel met minimale inspanning te begrijpen.

In deze blogpost laten we u zien hoe u langlopende MySQL-query's kunt detecteren met ClusterControl.

Waarom duurt een zoekopdracht langer?

Allereerst moeten we de aard van de query kennen, of het naar verwachting een langlopende of een kortlopende query zal zijn. 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 het ALTER-commando ook een langdurige operatie zijn.

Voor een transactie van korte duur moet deze zo snel mogelijk worden uitgevoerd, meestal in een kwestie van subseconde. Hoe korter hoe beter. Dit wordt geleverd met een reeks best-practiceregels voor zoekopdrachten die gebruikers moeten volgen, zoals het gebruik van de juiste indexering in de WHERE- of JOIN-instructie, het gebruik van de juiste opslagengine, het kiezen van de juiste gegevenstypen, het plannen van de batchbewerking tijdens daluren, het ontlasten van analytische /rapportage van verkeer naar speciale replica's, enzovoort.

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

Inefficiënte zoekopdracht - Gebruik niet-geïndexeerde kolommen tijdens het opzoeken of deelnemen, waardoor MySQL meer tijd nodig heeft om aan de voorwaarde te voldoen.
Tabelvergrendeling - De tabel is vergrendeld door globale vergrendeling of expliciete tabelvergrendeling wanneer de query toegang probeert te krijgen.
Deadlock - Een zoekopdracht wacht om toegang te krijgen tot dezelfde rijen die zijn vergrendeld door een andere zoekopdracht.
Dataset past niet in RAM - Als uw werksetgegevens in die cache passen, zullen SELECT-query's meestal relatief snel zijn.
Suboptimale hardwarebronnen - Dit kunnen trage schijven, RAID-reconstructie, verzadigd netwerk, enz. zijn.
Onderhoudsoperatie - Het uitvoeren van mysqldump kan enorme hoeveelheden anders ongebruikte gegevens in de bufferpool brengen, en tegelijkertijd worden de (mogelijk bruikbare) gegevens die er al zijn verwijderd en naar de schijf gespoeld.

De bovenstaande lijst benadrukt dat het niet alleen de query zelf is die allerlei problemen veroorzaakt. Er zijn tal van redenen die vereisen dat naar verschillende aspecten van een MySQL-server wordt gekeken. In het ergste geval kan een langlopende query een totale verstoring van de service veroorzaken, zoals server-down, servercrash en maximale verbindingen. Als u ziet dat het langer duurt dan normaal om een zoekopdracht uit te voeren, moet u deze onderzoeken.

Hoe te controleren?

PROCESSLIJST

MySQL biedt een aantal ingebouwde tools om de langlopende transactie te controleren. Ten eerste kunnen de opdrachten SHOW PROCESSLIST of SHOW FULL PROCESSLIST de lopende query's in realtime weergeven. Hier is een screenshot van de functie ClusterControl Running Queries, vergelijkbaar met de opdracht SHOW FULL PROCESSLIST (maar ClusterControl voegt het hele proces samen in één weergave voor alle knooppunten in het cluster):

Zoals u kunt zien, kunnen we de aanstootgevende zoekopdracht meteen vanaf de uitvoer zien. Maar hoe vaak staren we naar die processen? Dit is alleen nuttig 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.

Langzaam zoekopdrachtlogboek

Logboek met trage query's legt langzame query's vast (SQL-instructies die meer dan long_query_time in beslag nemen seconden 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
long_query_time=0.1
log_queries_not_using_indexes=1

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

ClusterControl Top Queries vat de langzame query samen met behulp van twee methoden:MySQL trage querylog of prestatieschema:

U kunt eenvoudig een samenvatting zien van de genormaliseerde overzichtsoverzichten, gesorteerd op basis van een aantal criteria:

Gastheer
Voorvallen
Totale uitvoeringstijd
Maximale uitvoeringstijd
Gemiddelde uitvoeringstijd
Tijd voor standaarddeviatie

We hebben deze functie uitgebreid besproken in deze blogpost, Hoe gebruik je de ClusterControl Query Monitor voor MySQL, MariaDB en Percona Server.

Prestatieschema

Prestatieschema is een geweldige tool die beschikbaar is voor het bewaken van de interne onderdelen en uitvoeringsdetails van MySQL Server op een lager niveau. 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 bevat het sys-schema, een set objecten die DBA's en ontwikkelaars helpt om de door het prestatieschema verzamelde gegevens te interpreteren in een meer begrijpelijke vorm. Sys-schema-objecten kunnen worden gebruikt voor typische gevallen van afstemming en diagnose.

ClusterControl biedt adviseurs, dit zijn miniprogramma's die u kunt schrijven met ClusterControl DSL (vergelijkbaar met JavaScript) om de monitoringmogelijkheden van ClusterControl op maat uit te breiden naar uw behoeften. Er zijn een aantal scripts opgenomen op basis van het prestatieschema die u kunt gebruiken om de prestaties van query's te controleren, zoals I/O-wachttijd, vergrendelingswachttijd enzovoort. Bijvoorbeeld onder Beheren -> Developer Studio , ga naar s9s -> mysql -> p_s -> top_tables_by_iowait.js en klik op de knop "Compileren en uitvoeren". U zou de uitvoer moeten zien op het tabblad Berichten voor de top 10 tabellen, gesorteerd op I/O-wachttijd per server:

Er zijn een aantal scripts die u kunt gebruiken om informatie op laag niveau te begrijpen waar en waarom de traagheid optreedt, zoals top_tables_by_lockwait.js , top_accessed_db_files.js enzovoort.

ClusterControl - Detectie en waarschuwing bij langlopende zoekopdrachten

Met ClusterControl krijgt u extra krachtige functies die u niet zult vinden in de standaard MySQL-installatie. ClusterControl kan worden geconfigureerd om de lopende processen proactief te bewaken en alarm te slaan en een melding naar de gebruiker te sturen als de lange vraagdrempel wordt overschreden. Dit kan worden geconfigureerd met behulp van de Runtime-configuratie onder Instellingen:

Voor pre1.7.1 is de standaardwaarde voor query_monitor_alert_long_running_query is fout. We moedigen de gebruiker aan om dit in te schakelen door het in te stellen op 1 (true). Om het persistent te maken, voegt u de volgende regel toe aan /etc/cmon.d/cmon_X.cnf:

query_monitor_alert_long_running_query=1
query_monitor_long_running_query_ms=30000

Alle wijzigingen die in de runtime-configuratie zijn aangebracht, worden onmiddellijk toegepast en opnieuw opstarten is niet nodig. U ziet zoiets als dit onder het gedeelte Alarmen als een zoekopdracht de drempels van 30000 ms (30 seconden) overschrijdt:

Als u de instellingen voor de e-mailontvanger configureert als "Bezorgen" voor de ernstcategorie DbComponent plus CRITICAL (zoals weergegeven in de volgende schermafbeelding):

U zou een kopie van dit alarm in uw e-mail moeten ontvangen. Anders kan het handmatig worden doorgestuurd door op de knop "E-mail verzenden" te klikken.

Bovendien kunt u alle soorten proceslijstbronnen die aan bepaalde criteria voldoen, uitfilteren met reguliere expressie (regex). Als u bijvoorbeeld wilt dat ClusterControl langlopende query's detecteert voor drie MySQL-gebruikers genaamd 'sbtest', 'myshop' en 'db_user1', moet u het volgende doen:

Alle wijzigingen die in de runtime-configuratie zijn aangebracht, worden onmiddellijk toegepast en opnieuw opstarten is niet nodig.

Bovendien zal ClusterControl alle deadlock-transacties samen met de InnoDB-status weergeven wanneer deze plaatsvond onder Prestaties -> Transactielogboek :

Deze functie is standaard niet ingeschakeld, omdat deadlock-detectie het CPU-gebruik op databaseknooppunten zal beïnvloeden. Om het in te schakelen, vinkt u eenvoudig het selectievakje "Transactielogboek inschakelen" aan en geeft u het gewenste interval op. Om het persistent te maken, voegt u een variabele toe met een waarde in seconden binnen /etc/cmon.d/cmon_X.cnf:

db_deadlock_check_interval=30

Evenzo, als u de InnoDB-status wilt bekijken, gaat u gewoon naar Performance -> InnoDB-status , en kies de MySQL-server in de vervolgkeuzelijst. Bijvoorbeeld:

Daar gaan we - alle benodigde informatie is gemakkelijk terug te vinden in een paar klikken.

Samenvatting

Langlopende transacties kunnen leiden tot prestatievermindering, serverstoringen, maximale verbindingen en impasses. Met ClusterControl kunt u langlopende query's rechtstreeks vanuit de gebruikersinterface detecteren, zonder dat u elk afzonderlijk MySQL-knooppunt in het cluster hoeft te onderzoeken.