Effectieve monitoring van MySQL met SCUMM-dashboards:deel 3

We bespraken in onze vorige blogs over de MySQL-gerelateerde dashboards. We hebben de dingen benadrukt waar een DBA van kan profiteren door de grafieken te bestuderen, vooral bij het uitvoeren van hun dagelijkse routines van diagnostiek, metrische rapportage en capaciteitsplanning. In deze blog bespreken we de InnoDB-statistieken en het MySQL-prestatieschema, wat erg belangrijk is, vooral bij het bewaken van InnoDB-transacties, schijf/cpu/geheugen-I/O, het optimaliseren van uw zoekopdrachten of het afstemmen van de prestaties van de server.

Deze blog raakt het diepgaande onderwerp van prestaties, aangezien InnoDB uitgebreide aandacht zou vereisen als we de interne aspecten ervan aanpakken. Het prestatieschema is ook uitgebreid omdat het de kern- en kernonderdelen van MySQL en opslagengines omvat.

Laten we beginnen door de grafieken te lopen.

MySQL InnoDB-statistieken

Dit dashboard is geweldig voor elke MySQL DBA- of ops-persoon, omdat het een zeer goed zicht biedt op de InnoDB-opslagengine. Er zijn hier bepaalde grafieken die een gebruiker moet overwegen om in te schakelen, omdat niet in alle situaties de variabelen correct zijn ingesteld in de MySQL-configuratie.

• Innodb Checkpoint-leeftijd

  Volgens de handleiding wordt checkpointing als volgt gedefinieerd:"Als er wijzigingen worden aangebracht aan gegevenspagina's die in de bufferpool worden opgeslagen , die wijzigingen worden weggeschreven naar de gegevensbestanden enige tijd later, een proces dat bekend staat als flushing . Het controlepunt is een overzicht van de laatste wijzigingen (weergegeven door een LSN waarde) die met succes naar de gegevensbestanden zijn geschreven ”. Deze grafiek is handig wanneer u wilt bepalen hoe uw server controlepuntgegevens op uw schijf uitvoert. Dit kan een goede referentie zijn als uw transactielogboek (redo-log of ib_logfile0) te groot is. Deze grafiek is ook een goede indicator als u variabelen zoals innodb_log_file_size, innodb_log_buffer_size, innodb_max_dirty_pages_pct of innodb_adaptive_flushing_method moet aanpassen. Hoe dichter de checkpointleeftijd bij de maximale checkpointleeftijd ligt, hoe meer de logs gevuld zijn en InnoDB zal meer I/O doen om wat vrije ruimte in de logs te behouden. Het controlemechanisme verschilt in subtiele details tussen Percona XtraDB-gebaseerde smaken, MariaDB en Oracle's versie, je kunt ook verschillen vinden in de implementatie tussen MySQL-versies.

• InnoDB-transacties

  Wanneer er een grote transactie gaande is op uw MySQL-server, is deze grafiek een goede referentie. Het telt de transacties die op een bepaald tijdstip zijn gemaakt, en de lengte van de geschiedenis (of is eigenlijk de lengte van de geschiedenislijst gevonden in SHOW ENGINE INNODB STATUS) is het aantal pagina's in het logboek voor ongedaan maken. De trends die u hier ziet, zijn een goede bron om te controleren of het bijvoorbeeld kan betekenen dat het opschonen wordt vertraagd vanwege een zeer hoge invoegsnelheid bij het opnieuw laden van de gegevens of vanwege een langlopende transactie, of dat het opschonen gewoon kan niet bijhouden vanwege een hoge schijf-I/O in het volume waar uw $DATADIR zich bevindt.

• Innodb-rijbewerkingen

  Voor bepaalde DBA-taken wilt u wellicht het aantal verwijderingen, invoegingen, leesbewerkingen en bijgewerkte rijen bepalen. Dan kunt u deze grafiek gebruiken om deze te controleren.

• Innodb rijvergrendelingstijd

  Deze grafiek is een goede bron om naar te kijken wanneer u merkt dat uw toepassing veel voorvallen tegenkomt voor "Lock wait time-out overschreden; probeer de transactie opnieuw te starten ”. Dit kan je ook helpen te bepalen of je een indicatie hebt voor het gebruik van slechte queries bij het afhandelen van sloten. Dit is ook een goede referentie om naar te kijken bij het optimaliseren van uw zoekopdrachten waarbij rijen worden vergrendeld. Als de wachttijd te lang is, moet u het logbestand voor trage zoekopdrachten controleren of een pt-query-digest uitvoeren om te zien welke verdachte zoekopdrachten die opgeblazenheid in de grafiek veroorzaken.

  

• InnoDB I/O

  Wanneer u de hoeveelheid InnoDB-gegevenslezingen, schijfspoelingen, schrijfbewerkingen en logschrijfbewerkingen wilt bepalen, heeft deze grafiek waar u naar moet kijken. U kunt deze grafiek gebruiken om te bepalen of uw InnoDB-variabelen goed zijn afgestemd op uw specifieke vereisten. Als u bijvoorbeeld de cache van de batterijback-upmodule hebt, maar u krijgt niet veel van de optimale prestaties, kunt u op deze grafiek vertrouwen om te bepalen of uw fsyncs() hoger zijn dan verwacht. Dan kan het probleem worden opgelost door de variabele innodb_flush_method te wijzigen en O_DSYNC te gebruiken.

• Gebruik van InnoDB-logbestand per uur

  Deze grafiek toont alleen het aantal bytes dat is geschreven naar de InnoDB-logbestanden voor opnieuw uitvoeren en de groei van uw InnoDB-logbestanden op basis van het 24-uurs tijdbereik van de huidige datum.

• InnoDB-logboekprestaties

  Deze grafiek is nauw verwant aan de InnoDB-grafiek voor gebruik van logbestanden per uur. U moet deze grafiek gebruiken wanneer u wilt bepalen hoe groot uw innodb_log_file_size moet zijn. U kunt het aantal bytes bepalen dat naar de logbestanden van InnoDB opnieuw wordt geschreven en hoe efficiënt uw MySQL gegevens van het geheugen naar de schijf verwijdert. Wanneer je weinig tijd hebt om je log-ruimte voor opnieuw uitvoeren te gebruiken, dan zou dit aangeven dat je je innodb_log_file-grootte moet vergroten. In dat geval zou deze grafiek u vertellen dat u dit moet doen. Om echter meer te weten te komen over hoeveel je nodig hebt voor je innodb_log_file, is het misschien logischer om de LSN (Log Sequence Number) in SHOW ENGINE INNODB STATUS te controleren. Percona heeft hierover een goede blog, wat een goede bron is om naar te kijken.

• InnoDB-impasses

  In bepaalde situaties waarin uw applicatieclient vaak deadlocks ervaart of u moet kijken naar hoeveel uw MySQL deadlocks ervaart, dient deze grafiek het doel. Deadlocks geven aan dat je een slecht SQL-ontwerp hebt, wat ertoe leidt dat je transacties een race-conditie creëren die deadlocks veroorzaakt.

• Indexvoorwaarde pushdown

  Een kleine waarschuwing bij het bekijken van deze grafiek. Eerst moet je bepalen of je MySQL-globale variabele innodb_monitor_enable hebt ingesteld op de juiste waarde, namelijk module_icp. Anders ervaart u een "Geen gegevenspunten" zoals hieronder weergegeven:

  

  Het doel van de grafiek, als gegevenspunten zijn gedefinieerd als wat ik heb in de voorbeelduitvoer, zal een DBA een overzicht geven van hoe goed uw zoekopdrachten profiteren met Index Condition Pushdown of kortweg ICP. ICP is een geweldige functie in MySQL die optimalisatie voor uw vragen biedt. In plaats van dat MySQL de volledige rijen leest die zijn gefilterd in uw WHERE-query's bij het ophalen, voegt het meer controles toe na uw secundaire indexen. Dit voegt meer granulariteit toe en bespaart tijd, anders moet de engine in plaats daarvan de volledige tabelrijen lezen wanneer deze alleen is gebaseerd op de gefilterde index en er geen ICP wordt gebruikt. Dit vermijdt het lezen van de volledige rijen die overeenkomen met uw indextuples die overeenkomen met uw secundaire indexen.

  Laat me wat dieper ingaan op deze grafiek, laten we zeggen dat ik een tabel heb met de naam:

  mysql> show create table a\G
  *************************** 1. row ***************************
         Table: a
  Create Table: CREATE TABLE `a` (
    `id` int(11) NOT NULL,
    `age` int(11) NOT NULL,
    KEY `id` (`id`)
  ) ENGINE=InnoDB DEFAULT CHARSET=latin1
  1 row in set (0.00 sec)

  En heeft wat kleine gegevens:

  mysql> select * from a;
  +----+-----+
  | id | age |
  +----+-----+
  |  1 |   1 |
  |  2 |   1 |
  |  3 |   1 |
  |  3 |  41 |
  |  4 |  41 |
  |  5 |   4 |
  |  4 |   4 |
  |  4 |   4 |
  +----+-----+
  8 rows in set (0.00 sec)

  Als ICP is ingeschakeld, zijn de resultaten efficiënter en haalbaarder:

  mysql> explain extended select * from a where id>2 and id<4 and age=41;
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
  | id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra                              |
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
  |  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using index condition; Using where |
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
  1 row in set, 2 warnings (0.00 sec)

  Dan zonder ICP,

  mysql> set optimizer_switch='index_condition_pushdown=off';
  Query OK, 0 rows affected (0.00 sec)
  
  mysql> explain extended select * from a where id>2 and id<4 and age=41;
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
  | id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
  |  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using where |
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
  1 row in set, 2 warnings (0.00 sec)

  Dit is een eenvoudig voorbeeld van ICP en hoe deze grafiek een DBA ten goede kan komen.

  

• InnoDB-bufferpoolinhoud

  Wanneer u met MySQL werkt en de InnoDB-engine gebruikt, is deze grafiek een van de meest voorkomende waarden (innodb_buffer_pool*) die u moet aanpassen om de MySQL-prestaties te optimaliseren. Specifiek gesproken over de inhoud van de bufferpool, toont het de trends voor vuile pagina's tegen de totale inhoud van de bufferpool. De totale inhoud van de bufferpool omvat de schone pagina's naast de vuile pagina's. Deze grafiek bepaalt hoe efficiënt uw MySQL omgaat met de bufferpool.

• InnoDB-bufferpoolpagina's

  Deze grafiek is handig als u wilt controleren hoe efficiënt MySQL uw InnoDB-bufferpool gebruikt. U kunt deze grafiek bijvoorbeeld gebruiken als uw dagelijkse verkeer de toegewezen innodb_buffer_pool_size niet vult, dan kan dit erop wijzen dat bepaalde delen van een toepassing niet nuttig zijn of geen enkel doel dienen of als u de innodb_buffer_pool_size erg hoog instelt wat misschien goed is om de waarde te verlagen en ruimte terug te winnen in je geheugen.

• InnoDB Buffer Pool I/O

  Wanneer u het aantal pagina's moet controleren dat is gemaakt en geschreven op InnoDB-tabellen of pagina's die naar de InnoDB-bufferpool worden gelezen door bewerkingen op InnoDB-tabellen.

• InnoDB-bufferpoolverzoeken

  Wanneer u wilt bepalen hoe efficiënt uw query's toegang krijgen tot de InnoDB-bufferpool, dient deze grafiek. Deze grafiek toont de trends op basis van de gegevenspunten over hoe uw MySQL-server presteert wanneer de InnoDB-engine vaak toegang moet krijgen tot de schijf (indicatie dat de bufferpool nog niet is opgewarmd), hoe vaak de bufferpoolverzoeken lees- en schrijfverzoeken verwerkten verzoeken.

• InnoDB Read-Ahead

  Als je de variabele innodb_random_read_ahead hebt ingesteld op ON, voeg dan deze grafiek toe als een waardevolle trend om naar te kijken als onderdeel van je DBA-routine. Het toont de trends over hoe uw MySQL InnoDB-opslagengine de bufferpool beheert door de read-ahead-achtergrondthread, hoe het de bufferpools beheert die vervolgens worden uitgezet zonder dat ze door query's zijn benaderd, en hoe InnoDB de willekeurige read-ahead initieert wanneer een query wordt gescand een groot deel van een tafel maar in willekeurige volgorde.

  

• InnoDB-wijzigingsbuffer

  Als Percona Server 5.7 draait, is deze grafiek handig om te controleren hoe goed InnoDB wijzigingsbuffering heeft toegewezen. Deze wijzigingen omvatten de invoegingen, updates en verwijderingen die zijn gespecificeerd door de variabele innodb_change_buffering. Wijzigingsbuffering helpt bij het versnellen van zoekopdrachten, waardoor substantiële willekeurige toegang I/O wordt vermeden die nodig zou zijn om secundaire indexpagina's van schijf in te lezen.

• InnoDB Wijzig Buffer Activiteit

  Dit is gerelateerd aan de InnoDB Change Buffer-grafiek, maar ontleedt de informatie in meer bruikbare datapunten. Deze bieden meer informatie om te controleren hoe InnoDB omgaat met wijzigingsbuffering. Dit is handig bij een bepaalde DBA-taak om te bepalen of uw innodb_change_buffer_max_size is ingesteld op een te hoge waarde, aangezien de wijzigingsbuffer hetzelfde geheugen deelt als de InnoDB-bufferpool, waardoor er minder geheugen beschikbaar is om gegevenspagina's in de cache op te slaan. U moet wellicht overwegen om wijzigingsbuffering uit te schakelen als de werkset bijna in de bufferpool past, of als uw tabellen relatief weinig secundaire indexen hebben. Onthoud dat het bufferen van wijzigingen geen extra overhead met zich meebrengt, omdat het alleen van toepassing is op pagina's die zich niet in de bufferpool bevinden. Deze grafiek is ook handig als u moet bepalen hoe samenvoegingen nuttig zijn als u uw toepassing moet benchmarken op basis van bepaalde verzoeken voor bepaalde scenario's. Stel dat u bulk-inserts hebt, u moet innodb_change_buffering=insert instellen en bepalen of de waarden die zijn ingesteld in uw bufferpool en innodb_change_buffer_max_size geen invloed hebben op schijf-I/O, vooral tijdens herstel of langzaam afsluiten (noodzakelijk als u een failover met een lage downtime-eis). Deze grafiek kan ook uw doel dienen om bepaalde scenario's te evalueren, aangezien het samenvoegen van de wijzigingsbuffer enkele uren kan duren wanneer er talrijke secundaire indexen zijn om bij te werken en veel betrokken rijen. Gedurende deze tijd wordt de schijf-I/O verhoogd, wat een aanzienlijke vertraging kan veroorzaken bij schijfgebonden zoekopdrachten.

MySQL-prestatieschema

Het MySQL-prestatieschema is een ingewikkeld onderwerp. Het is een lange en moeilijke, maar ik ga alleen informatie bespreken die specifiek is voor de grafieken die we in SCUMM hebben. Er zijn ook bepaalde variabelen waarmee u rekening moet houden en ervoor moet zorgen dat deze correct zijn ingesteld. Zorg ervoor dat u uw variabele innodb_monitor_enable =all en userstat=1 hebt om gegevenspunten in uw grafieken te zien. Als een opmerking, als ik hier het woord "event" gebruik, betekent dit niet dat dit gerelateerd is aan MySQL Event Scheduler. Ik heb het over specifieke gebeurtenissen zoals MySQL die een query ontleedt, MySQL leest of schrijft naar relais/binair logbestand, enz.

Laten we dan verder gaan met de grafieken.

• Prestatieschema Bestand IO (Gebeurtenissen)

  Deze grafiek haalt gegevenspunten op met betrekking tot gebeurtenissen die zich hebben voorgedaan in MySQL en die mogelijk zijn geïnstrumenteerd om meerdere instanties van het geïnstrumenteerde object te maken (bijv. binaire log-lezingen of InnoDB-gegevensbestand-lezingen). Elke rij vat gebeurtenissen voor een bepaalde gebeurtenisnaam samen. Als er bijvoorbeeld een instrument voor een mutex is dat voor elke verbinding wordt gemaakt, dan kunnen er veel gevallen zijn van deze geïnstrumenteerde gebeurtenis omdat er meerdere verbindingen zijn. De samenvattingsrij voor het instrument geeft een overzicht van al deze instanties. U kunt deze gebeurtenissen bekijken in de MySQL-handleiding voor prestatieschema-overzichtstabellen voor meer informatie.

• Prestatieschemabestand IO (laden)

  Deze grafiek is hetzelfde als de grafiek "Performance Schema File IO (Events)", behalve dat deze is geïnstrumenteerd op basis van de belasting.

• Prestatieschemabestand IO (bytes)

  Deze grafiek is hetzelfde als de grafiek "Performance Schema File IO (Events)", behalve dat deze is geïnstrumenteerd op basis van de grootte in bytes. Hoeveel tijd duurde bijvoorbeeld een specifieke gebeurtenis toen MySQL de gebeurtenis wait/io/file/innodb/innodb_data_file activeerde.

• Prestatieschema wacht (gebeurtenissen)

  Deze grafiek bevat de gegevensgrafiek voor alle wachttijden die zijn besteed aan een specifieke gebeurtenis. U kunt de overzichtstabellen van wachtgebeurtenissen in de handleiding raadplegen voor meer informatie.

  

• Prestatieschema wacht (laden)

  Hetzelfde als de grafiek 'Performance Schema Waits (Events)', maar deze keer toont het de trends voor de belasting.

• Indextoegangsbewerkingen (laden)

  Deze grafiek is een aggregatie van alle tabelindex I/O-wachtgebeurtenissen, gegroepeerd op index(en) van een tabel, zoals gegenereerd door het wait/io/table/sql/handler-instrument. U kunt de MySQL-handleiding over de prestatieschematabel table_io_waits_summary_by_index_usage raadplegen voor meer informatie.

• Tafeltoegangsbewerkingen (laden)

  "Hetzelfde als Index Access Operations (Load)" grafiek, het is een aggregatie van alle tabel I/O wachtgebeurtenissen groep voor tabel, zoals gegenereerd door het wait/io/table/sql/handler instrument. Dit is erg handig voor DBA's. U wilt bijvoorbeeld nagaan hoe snel het duurt om toegang te krijgen (ophalen) of bij te werken (invoegen, verwijderen, bijwerken) van een specifieke tabel. U kunt de MySQL-handleiding raadplegen over de prestatieschematabel table_io_waits_summary_by_table voor meer informatie.

  

• Prestatieschema SQL en externe vergrendelingen (gebeurtenissen)

  Deze grafiek is een aggregatie (tellingen van hoe vaak het is voorgekomen) van alle wachtgebeurtenissen voor tafelvergrendeling, zoals gegenereerd door het wait/lock/table/sql/handler-instrument dat is gegroepeerd per tabel. Het SQL-slot hier in de grafiek betekent de interne sloten. Deze interne vergrendelingen zijn normaal lezen, lezen met gedeelde vergrendelingen, lezen hoge prioriteit, lezen niet invoegen, schrijven toestaan ​​schrijven, gelijktijdig schrijven invoegen, schrijven vertraagd, schrijven lage prioriteit, schrijven normaal. Terwijl de externe sloten extern worden gelezen en extern worden geschreven. In elke DBA-taak is dit erg handig als u vergrendelingen op een bepaalde tafel moet traceren en onderzoeken, ongeacht het type. U kunt de tabel table_lock_waits_summary_by_table raadplegen voor meer informatie.

• Prestatieschema SQL en externe vergrendelingen (seconden)

  Hetzelfde als de grafiek "Prestatieschema SQL en externe vergrendelingen (gebeurtenissen)", maar gespecificeerd in seconden. Als u uw tafelvergrendelingen wilt zoeken op basis van seconden waarin deze de vergrendelingen vasthielden, dan is deze grafiek uw goede hulpbron.

Conclusie

De InnoDB Metrics en MySQL Performance Schema zijn enkele van de meest diepgaande en gecompliceerde onderdelen in het MySQL-domein, vooral wanneer er geen visualisatie is om de interpretatie te vergemakkelijken. Dus het handmatig traceren en onderzoeken kan wat van uw tijd en hard werk vergen. SCUMM-dashboards bieden een zeer efficiënte en haalbare manier om hiermee om te gaan en de extra belasting van elke DBA-routinetaak te verminderen.

In deze blog heb je geleerd hoe je de dashboards voor InnoDB en Performance Schema kunt gebruiken om de databaseprestaties te verbeteren. Met deze dashboards kunt u de prestaties efficiënter analyseren.