Slechte queryprestaties zijn het meest voorkomende probleem waarmee DBA's te maken hebben. Er zijn talloze manieren om de gegevens met betrekking tot queryprestaties te verzamelen, verwerken en analyseren - we hebben een van de meest populaire tools, pt-query-digest, behandeld in enkele van onze eerdere blogposts:
Word een MySQL DBA-blogreeks
- Uw SQL-werklast analyseren met pt-query-digest
- Deep Dive SQL-werkbelastinganalyse met pt-query-digest
Wanneer u ClusterControl gebruikt, is dit echter niet altijd nodig. U kunt de gegevens die beschikbaar zijn in ClusterControl gebruiken om uw probleem op te lossen. In deze blogpost bekijken we hoe ClusterControl u kan helpen bij het oplossen van problemen met betrekking tot queryprestaties.
Het kan voorkomen dat een zoekopdracht niet tijdig kan worden afgerond. De zoekopdracht kan vastlopen vanwege een aantal vergrendelingsproblemen, deze is mogelijk niet optimaal of niet goed geïndexeerd of is te zwaar om binnen een redelijke tijd te voltooien. Houd er rekening mee dat een aantal niet-geïndexeerde joins gemakkelijk miljarden rijen kunnen scannen als u een grote productiedatabase hebt. Wat er ook is gebeurd, de query gebruikt waarschijnlijk een deel van de bronnen - of het nu CPU of I/O is voor een niet-geoptimaliseerde query of zelfs alleen rijvergrendelingen. Die bronnen zijn ook nodig voor andere vragen en het kan de zaken ernstig vertragen. Een van de zeer eenvoudige maar belangrijke taken zou zijn om de gewraakte zoekopdracht te lokaliseren en te stoppen.
Het is vrij eenvoudig te doen vanuit de ClusterControl-interface. Ga naar het tabblad Query Monitor -> Query's uitvoeren sectie - u zou een uitvoer moeten zien die lijkt op de onderstaande schermafbeelding.
Zoals je kunt zien, hebben we een stapel vragen vastgelopen. Meestal is de beledigende zoekopdracht degene die lang duurt, je zou hem misschien willen doden. U kunt het ook verder onderzoeken om er zeker van te zijn dat u de juiste kiest. In ons geval zien we duidelijk een SELECT ... FOR UPDATE die een aantal tabellen verbindt en die in de status 'Gegevens wordt verzonden', wat betekent dat het de gegevens verwerkt, gedurende de laatste 90 seconden.
Een ander type vraag dat een DBA mogelijk moet beantwoorden, is:welke query's nemen de meeste tijd in beslag om uit te voeren? Dit is een veel voorkomende vraag, aangezien dergelijke zoekopdrachten een laaghangend fruit kunnen zijn - ze kunnen worden geoptimaliseerd, en hoe meer uitvoeringstijd een bepaalde zoekopdracht verantwoordelijk is in een hele zoekopdrachtmix, hoe groter de winst van de optimalisatie ervan. Het is een simpele vergelijking:als een zoekopdracht verantwoordelijk is voor 50% van de totale uitvoeringstijd, zal 10x sneller een veel beter resultaat opleveren dan het optimaliseren van een zoekopdracht die verantwoordelijk is voor slechts 1% van de totale uitvoeringstijd.
ClusterControl kan u helpen dergelijke vragen te beantwoorden, maar eerst moeten we ervoor zorgen dat de Query Monitor is ingeschakeld. U kunt de Query Monitor op AAN zetten op de pagina Query Monitor. Verder kunt u de optie "Lange querytijd" en "Logquery's zonder indexen" configureren onder Instellingen om aan uw werklast te voldoen:
De Query Monitor in ClusterControl werkt in twee modi, afhankelijk van of u het Performance Schema met de vereiste gegevens over de lopende query's beschikbaar hebt of niet. Als het beschikbaar is (en dit is standaard het geval in MySQL 5.6 en nieuwer), wordt het prestatieschema gebruikt om querygegevens te verzamelen, waardoor de impact op het systeem wordt geminimaliseerd. Anders wordt het logbestand voor langzame zoekopdrachten gebruikt en worden alle instellingen gebruikt die zichtbaar zijn in de bovenstaande schermafbeelding. Die worden vrij goed uitgelegd in de gebruikersinterface, dus het is niet nodig om het hier te doen. Wanneer de Query Monitor prestatieschema gebruikt, worden die instellingen niet gebruikt (behalve voor het AAN/UIT zetten van de Query Monitor om gegevensverzameling in/uit te schakelen).
Wanneer u hebt bevestigd dat de Query Monitor is ingeschakeld in ClusterControl, kunt u naar Query Monitor -> Top Queries gaan, waar u een scherm krijgt dat lijkt op het onderstaande:
Wat u hier kunt zien, is een lijst met de duurste query's (in termen van uitvoeringstijd) die ons cluster hebben getroffen. Elk van hen heeft enkele verdere details - hoe vaak het werd uitgevoerd, hoeveel rijen werden onderzocht of naar de klant werden verzonden, hoe de uitvoeringstijd varieerde, hoeveel tijd het cluster besteedde aan het uitvoeren van een bepaald type query. Query's zijn gegroepeerd op querytype en schema.
Het zal je misschien verbazen dat de belangrijkste plaats waar de uitvoeringstijd wordt besteed, een 'COMMIT'-query is. Dit is eigenlijk vrij typisch voor snelle OLTP-query's die worden uitgevoerd op het Galera-cluster. Het aangaan van een transactie is een kostbaar proces omdat certificering moet plaatsvinden. Dit leidt ertoe dat COMMIT een van de meest tijdrovende zoekopdrachten in de zoekopdrachtenmix is.
Wanneer u op een query klikt, ziet u de volledige query, maximale uitvoeringstijd, aantal keren dat het voorkomt, enkele algemene optimalisatietips en een EXPLAIN-uitvoer ervoor - best handig om te zien of er iets mis mee is. In ons voorbeeld hebben we een SELECT... FOR UPDATE aangevinkt met een groot aantal onderzochte rijen. Zoals verwacht is deze query een voorbeeld van verschrikkelijke SQL - een JOIN die geen enkele index gebruikt. U kunt op de EXPLAIN-uitvoer zien dat er geen index wordt gebruikt, er werd zelfs geen enkele als mogelijk beschouwd om te gebruiken. Geen wonder dat deze zoekopdracht de prestaties van ons cluster ernstig heeft beïnvloed.
Een andere manier om inzicht te krijgen in de prestaties van query's is door te kijken naar Query Monitor -> Query Outliers. Dit is in feite een lijst met zoekopdrachten waarvan de prestaties aanzienlijk verschillen van hun gemiddelde.
Zoals je kunt zien in de bovenstaande schermafbeelding, duurde de tweede query 0,01116s (de tijd wordt weergegeven in milliseconden), terwijl de gemiddelde uitvoeringstijd voor die query veel lager is (0,000142s). We hebben ook wat aanvullende statistische informatie over standaarddeviatie en maximale uitvoeringstijd van query's. Een dergelijke lijst met zoekopdrachten lijkt misschien niet erg nuttig - het is niet echt waar. Als u een zoekopdracht in deze lijst ziet, betekent dit dat er iets anders was dan gebruikelijk - de zoekopdracht is niet binnen de reguliere tijd voltooid. Het kan een indicatie zijn van prestatieproblemen op uw systeem en een signaal dat u andere statistieken moet onderzoeken en moet controleren of er op dat moment iets anders is gebeurd.
Mensen hebben de neiging om zich te concentreren op het behalen van maximale prestaties en vergeten dat een hoge doorvoer niet voldoende is - het moet ook consistent zijn. Gebruikers willen dat de prestaties stabiel zijn - je kunt misschien meer transacties per seconde uit je systeem persen, maar als dit betekent dat sommige transacties secondenlang vastlopen, is dat het niet waard. Als u naar het queryhistogram in ClusterControl kijkt, kunt u dergelijke consistentieproblemen in uw querymix identificeren.
Veel plezier bij het monitoren van zoekopdrachten!
PS.:Klik hier om aan de slag te gaan met ClusterControl!