Effektiv övervakning av MySQL med SCUMM Dashboards:Del 3

Vi diskuterade i våra tidigare bloggar om de MySQL-relaterade instrumentpanelerna. Vi lyfte fram de saker som en DBA kan dra nytta av genom att studera graferna, särskilt när de utför sina dagliga rutiner från diagnostik, metrisk rapportering och kapacitetsplanering. I den här bloggen kommer vi att diskutera InnoDB Metrics och MySQL Performance Schema, vilket är mycket viktigt, särskilt för att övervaka InnoDB-transaktioner, disk/cpu/minne I/O, optimera dina frågor eller prestandajustering av servern.

Den här bloggen berör det djupa ämnet prestanda, med tanke på att InnoDB skulle kräva omfattande täckning om vi tar itu med dess interna delar. Prestandaschemat är också omfattande eftersom det täcker kärnan och kärndelar av MySQL och lagringsmotorer.

Låt oss börja gå igenom graferna.

MySQL InnoDB-statistik

Den här instrumentbrädan är bra för alla MySQL DBA- eller ops-personer, eftersom den erbjuder en mycket bra inblick i InnoDB-lagringsmotorn. Det finns vissa grafer här som en användare måste överväga för att aktivera, eftersom inte i alla situationer variablerna är korrekt inställda i MySQL-konfigurationen.

• Innodb Checkpoint Age

  Enligt manualen definieras checkpointing enligt följande:"Eftersom ändringar görs på datasidor som är cachade i buffertpoolen , dessa ändringar skrivs till datafilerna någon gång senare, en process som kallas spolning . Kontrollpunkten är en registrering av de senaste ändringarna (representerad av ett LSN värde) som har skrivits till datafilerna ”. Den här grafen är användbar när du vill avgöra hur din server utför checkpointdata till din disk. Detta kan vara en bra referens om din transaktionslogg (redo-logg eller ib_logfile0) är för stor. Den här grafen är också en bra indikator om du behöver justera variabler som innodb_log_file_size,, innodb_log_buffer_size, innodb_max_dirty_pages_pct eller innodb_adaptive_flushing_method. Ju närmare checkpointåldern är den maximala checkpointåldern, desto mer fyllda är loggarna och InnoDB kommer att göra mer I/O för att behålla lite ledigt utrymme i loggarna. Checkpointing-mekanismen skiljer sig i subtila detaljer mellan Percona XtraDB-baserade smaker, MariaDB och Oracles version, du kan också hitta skillnader i dess implementering mellan MySQL-versioner.

• InnoDB-transaktioner

  Närhelst det pågår en stor transaktion i din MySQL-server är denna graf en bra referens. Det kommer att räkna transaktionerna som skapades vid en specifik tidpunkt, och historiklängden (eller är faktiskt historiklistans längd som finns i SHOW ENGINE INNODB STATUS) är antalet sidor i ångraloggen. Trenderna du kommer att se här är en bra resurs för att kontrollera om det till exempel kan betyda att rensningen är försenad på grund av en mycket hög insättningshastighet för omladdning av data eller på grund av en långvarig transaktion, eller om rensning helt enkelt kan hänger inte med på grund av en hög disk I/O i volymen där din $DATADIR finns.

• Innodb Row Operations

  För vissa DBA-uppgifter kanske du vill bestämma antalet raderingar, infogar, läsningar och uppdaterade rader. Då är den här grafen vad du kan använda för att kontrollera dessa.

• Innodb radlåstid

  Den här grafen är en bra resurs att titta på när du märker att din applikation stöter på många händelser för "Lås vänta timeout har överskridits; försök starta om transaktionen ”. Detta kan också hjälpa dig att avgöra om du kan ha en indikation på att använda dåliga frågor för att hantera lås. Detta är också en bra referens att titta på när du optimerar dina frågor som involverar låsning av rader. Om tiden att vänta är för lång måste du kontrollera den långsamma frågeloggen eller köra en pt-query-digest och se vad är de misstänkta frågorna som orsakar den svullnaden i grafen.

  

• InnoDB I/O

  Närhelst du vill bestämma mängden InnoDB-data som läses, diskspolar, skriver och loggar, har denna graf det du behöver titta på. Du kan använda den här grafen för att avgöra om dina InnoDB-variabler är väl inställda för att hantera dina specifika krav. Till exempel, om du har Battery Backup Module-cache men du inte får mycket av dess optimala prestanda, kan du lita på den här grafen för att avgöra om dina fsyncs() är högre än förväntat. Att sedan ändra variabeln innodb_flush_method och använda O_DSYNC kan lösa problemet.

• Användning av InnoDB-loggfil varje timme

  Det här diagrammet visar bara antalet byte som skrivits till InnoDB-loggfilerna för redogörelse och tillväxten av dina InnoDB-loggfiler baserat på 24-timmarsintervallet för det aktuella datumet.

• InnoDB-loggningsprestanda

  Denna graf är nära relaterad till InnoDB Log File Usage Timgraf. Du måste använda den här grafen när du behöver bestämma hur stor din innodb_log_file_size måste vara. Du kan bestämma antalet byte som skrivits till InnoDBs redo-loggfiler och hur effektivt din MySQL rensar data från minne till disk. Närhelst du upplever ett litet behov av att använda ditt redo-loggutrymme, skulle det indikera att du måste öka storleken på din innodb_log_file. I så fall skulle den här grafen berätta att du måste göra det. Men för att gräva mer i hur mycket du behöver för din innodb_log_file, kan det vara mer meningsfullt att kontrollera LSN (Log Sequence Number) i SHOW ENGINE INNODB STATUS. Percona har en bra blogg relaterad till detta som är en bra källa att titta på.

• InnoDB dödlägen

  I vissa situationer där din applikationsklient ofta upplever dödlägen eller du måste titta på hur mycket din MySQL upplever låsningar, tjänar denna graf syftet. Blockerade låsningar indikerar att du har dålig SQL-design vilket leder till att dina transaktioner skapar ett tävlingstillstånd som orsakar dödläge.

• Pushdown för indexvillkor

  Ett litet varningens ord när man tittar på denna graf. Först måste du bestämma att du har din MySQL globala variabel innodb_monitor_enable inställd på rätt värde som är module_icp. Annars kommer du att uppleva ett "Inga datapunkter" som visas nedan:

  

  Grafens syfte, om det har datapunkter definierade som vad jag har i exempelutdata, kommer att ge en DBA med en överblick över hur väl dina frågor gynnas med Index Condition Pushdown eller ICP för kort. ICP är en fantastisk funktion i MySQL som erbjuder optimering av dina frågor. Istället för att MySQL läser de fullständiga raderna som filtrerats i dina WHERE-frågor vid hämtning, kommer det att lägga till fler kontroller efter dina sekundära index. Detta ger mer granularitet och sparar tid, annars måste motorn läsa raderna i hela tabellen istället när den enbart baseras på det filtrerade indexet och ingen ICP används. Detta undviker att läsa de fullständiga raderna som motsvarar dina indextupler som matchar dina sekundära index.

  Låt mig utveckla lite om denna graf, låt säga att jag har en tabell som heter:

  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)

  Och har lite data:

  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)

  När ICP är aktiverat blir resultatet mer effektivt och genomförbart:

  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)

  Än utan 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)

  Detta är ett enkelt exempel på ICP och hur denna graf kan gynna en DBA.

  

• InnoDB buffertpoolinnehåll

  När du arbetar med MySQL och använder InnoDB-motorn är denna graf ett av de vanligaste värdena (innodb_buffer_pool*) som du måste ställa in för att optimera MySQL-prestanda. När det gäller innehållet i buffertpoolen visar den trenderna för smutsiga sidor mot det totala innehållet i buffertpoolen. Det totala innehållet i buffertpoolen inkluderar de rena sidorna förutom smutsiga sidor. Denna graf tjänar sitt syfte för att avgöra hur effektivt din MySQL hanterar buffertpoolen.

• InnoDB buffertpoolsidor

  Den här grafen är användbar när du vill kontrollera hur effektivt MySQL använder din InnoDB-buffertpool. Du kan till exempel använda den här grafen, om din dagliga trafik inte fyller upp den tilldelade innodb_buffer_pool_size, kan det tyda på att vissa delar av en applikation inte är användbara eller inte tjänar något syfte eller om du ställer in innodb_buffer_pool_size mycket högt vilket kan vara bra för att sänka värdet och ta tillbaka utrymmet till ditt minne.

• InnoDB Buffer Pool I/O

  När du måste kontrollera antalet sidor som skapats och skrivits på InnoDB-tabeller eller sidläsningar till InnoDB-buffertpoolen genom operationer på InnoDB-tabeller.

• InnoDB Buffer Pool Requests

  När du vill bestämma hur effektivt dina frågor är att komma åt InnoDB-buffertpoolen, tjänar denna graf syftet. Den här grafen visar trenderna baserat på datapunkterna om hur din MySQL-server fungerar när InnoDB-motorn ofta måste komma åt disken (indikation på att buffertpoolen inte har värmts upp ännu), hur ofta buffertpoolens förfrågningar hanterade läsbegäranden och skrivning förfrågningar.

• InnoDB Read-Ahead

  När du har variabeln innodb_random_read_ahead inställd på ON, lägg sedan till denna graf som en värdefull trend att titta på som en del av din DBA-rutin. Den visar trenderna för hur din MySQL InnoDB-lagringsmotor hanterar buffertpoolen med bakgrundstråden för läsning, hur den hanterar de som sedan vräkts utan att ha nåtts av frågor, och hur initierar InnoDB den slumpmässiga läsningen när en fråga skannar en stor del av ett bord men i slumpmässig ordning.

  

• InnoDB Change Buffer

  När du har Percona Server 5.7 igång är den här grafen användbar när du övervakar hur väl InnoDB har allokerat ändringsbuffring. Dessa ändringar inkluderar de infogningar, uppdateringar och borttagningar som specificeras av variabeln innodb_change_buffering. Ändringsbuffring hjälper till att snabba upp frågor och undviker betydande I/O för direktåtkomst som skulle krävas för att läsa in sekundära indexsidor från disken.

• InnoDB Change Buffer Activity

  Detta är relaterat till InnoDB Change Buffer-grafen, men dissekerar informationen till mer genomförbara datapunkter. Dessa ger mer information för att övervaka hur InnoDB hanterar ändringsbuffring. Detta är användbart i en viss DBA-uppgift för att avgöra om din innodb_change_buffer_max_size är inställd på ett för högt värde, eftersom ändringsbuffringen delar samma minne som InnoDB-buffertpoolen, vilket minskar det tillgängliga minnet för cachedatasidor. Du kanske måste överväga att inaktivera ändringsbuffring om arbetsuppsättningen nästan passar i buffertpoolen, eller om dina tabeller har relativt få sekundära index. Kom ihåg att ändringsbuffring inte medför extra overhead, eftersom det bara gäller sidor som inte finns i buffertpoolen. Den här grafen är också användbar om du måste bestämma hur sammanslagningar är användbara om du måste jämföra din applikation baserat på vissa förfrågningar för särskilda scenarier. Låt säga att du har en bulkinsert, du måste ställa in innodb_change_buffering=insert och avgöra om att ha värdena inställda i din buffertpool och innodb_change_buffer_max_size inte påverkar disk I/O, speciellt under återställning eller långsam avstängning (nödvändigt om du vill göra en failover med lågt stilleståndskrav). Den här grafen kan också tjäna ditt syfte att utvärdera vissa scenarier, eftersom sammanslagning av ändringsbuffert kan ta flera timmar när det finns många sekundära index att uppdatera och många påverkade rader. Under denna tid ökar disk I/O, vilket kan orsaka en betydande nedgång för diskbundna frågor.

MySQL Performance Schema

MySQL Performance Schema är ett komplicerat ämne. Det är en lång och svår sådan, men jag kommer bara att diskutera information som är specifik för de grafer vi har i SCUMM. Det finns också vissa variabler som du måste överväga och se till att de är korrekt inställda. Se till att du har din variabel innodb_monitor_enable =all och userstat=1 för att se datapunkter i dina grafer. Som en notering, när jag använder ordet "event" här, betyder det inte att detta är relaterat till MySQL Event Scheduler. Jag pratar om specifika händelser som att MySQL analyserar en fråga, MySQL läser eller skriver till relä/binär loggfil, etc.

Låt oss sedan fortsätta med graferna.

• Performance Schema File IO (Events)

  Den här grafen hämtar datapunkter relaterade till alla händelser som inträffade i MySQL som kan ha instrumenterats för att skapa flera instanser av det instrumenterade objektet (t.ex. binära loggläsningar eller InnoDB-datafilläsningar). Varje rad sammanfattar händelser för ett givet händelsenamn. Till exempel, om det finns ett instrument för en mutex som skapas för varje anslutning, kan det finnas många instanser av denna instrumenterade händelse eftersom det finns flera anslutningar. Sammanfattningsraden för instrumentet sammanfattar alla dessa instanser. Du kan kontrollera dessa händelser i MySQL-manualen för sammanfattningstabeller för prestandascheman för mer information.

• Performance Schema File IO (Load)

  Den här grafen är samma som grafen "Performance Schema File IO (Events)" förutom att den är instrumenterad baserat på belastningen.

• Performance Schema File IO (Bytes)

  Den här grafen är samma som grafen "Performance Schema File IO (Events)" förutom att den är instrumenterad baserat på storleken i byte. Till exempel, hur lång tid tog en specifik händelse när MySQL utlöste händelsen wait/io/file/innodb/innodb_data_file.

• Performance Schema Waits (händelser)

  Den här grafen har datadiagrammet för alla väntan som spenderas på en specifik händelse. Du kan kontrollera sammanfattningstabellerna för vänta händelser i manualen för mer information.

  

• Performance Schema Waits (load)

  Samma som grafen "Performance Schema Waits (Events)" men den här gången visar den trenderna för belastningen.

• Indexåtkomståtgärder (laddning)

  Den här grafen är en aggregering av alla I/O-vänthändelser för tabellindex grupperade efter index(er) för en tabell, som genereras av instrumentet wait/io/table/sql/hanterare. Du kan kontrollera MySQL-manualen om Performance Schema-tabellen table_io_waits_summary_by_index_usage för mer information.

• Table Access Operations (Load)

  "Samma som Index Access Operations (Load)"-grafen, det är en aggregering av alla tabell I/O-vänthändelser grupp för tabell, som genereras av wait/io/table/sql/hanterare-instrumentet. Detta är mycket användbart för DBA:er. Du skulle till exempel vilja spåra hur snabbt det tar att komma åt (hämta) eller uppdatera (infoga, ta bort, uppdatera) en specifik tabell. Du kan kolla i MySQL-manualen om Performance Schema-tabellen table_io_waits_summary_by_table för mer information.

  

• Prestandaschema SQL och externa lås (händelser)

  Den här grafen är en aggregering (antal av hur många gånger det inträffade) av alla väntande händelser för tabelllås, som genereras av instrumentet wait/lock/table/sql/hanterare som är grupp för tabell. SQL-låset här i grafen betyder de interna låsen. Dessa interna lås är läs normalt, läs med delade lås, läs hög prioritet, läs ingen infogning, skriv tillåt skriv, skriv samtidig infogning, skriv fördröjd, skriv låg prioritet, skriv normalt. Medan de externa låsen läses externt och skriver externt. I alla DBA-uppgifter är detta mycket användbart om du måste spåra och undersöka lås på ett visst bord oavsett dess typ. Du kan kontrollera tabellen table_lock_waits_summary_by_table för mer information.

• Prestandaschema SQL och externa lås (sekunder)

  Samma som grafen "Performance Schema SQL &External Locks (Events)", men specificeras i sekunder. Om du vill leta efter dina bordslås baserat på sekunder som den höll låsen, är den här grafen din bra resurs.

Slutsats

InnoDB Metrics och MySQL Performance Schema är några av de mest djupgående och komplicerade delarna i MySQL-domänen, särskilt när det inte finns någon visualisering för att underlätta tolkningen. Att gå till en manuell spårning och undersökningar kan därför ta lite tid och hårt arbete. SCUMM instrumentpaneler erbjuder ett mycket effektivt och genomförbart sätt att hantera dessa och minska den extra belastningen på alla rutinuppgifter för DBA.

I den här bloggen lärde du dig hur du använder instrumentpanelerna för InnoDB och Performance Schema för att förbättra databasprestanda. Dessa instrumentpaneler kan göra dig mer effektiv när det gäller att analysera prestanda.