Effektiv overvågning af MySQL med SCUMM Dashboards:Del 3

Vi diskuterede i vores tidligere blogs om de MySQL-relaterede dashboards. Vi fremhævede de ting, som en DBA kan drage fordel af ved at studere graferne, især når de udfører deres daglige rutiner fra diagnostik, metrisk rapportering og kapacitetsplanlægning. I denne blog vil vi diskutere InnoDB Metrics og MySQL Performance Schema, som er meget vigtigt, især ved overvågning af InnoDB-transaktioner, disk/cpu/hukommelse I/O, optimering af dine forespørgsler eller ydelsesjustering af serveren.

Denne blog berører det dybe emne om ydeevne i betragtning af, at InnoDB ville kræve omfattende dækning, hvis vi tackler dets interne. Ydeevneskemaet er også omfattende, da det dækker kerne- og kernedele af MySQL og storage-motorer.

Lad os begynde at gå gennem graferne.

MySQL InnoDB-metrics

Dette dashboard er fantastisk til enhver MySQL DBA eller ops person, da det giver et meget godt indblik i InnoDB storage motoren. Der er visse grafer her, som en bruger skal overveje for at aktivere, for det er ikke i alle situationer, at variablerne er indstillet korrekt i MySQL-konfigurationen.

• Innodb Checkpoint Age

  Ifølge manualen er checkpointing defineret som følger:"Da der foretages ændringer på datasider, der er cachelagret i bufferpuljen , disse ændringer skrives til datafilerne engang senere, en proces kendt som flushing . Kontrolpunktet er en registrering af de seneste ændringer (repræsenteret ved et LSN værdi), der er blevet skrevet til datafilerne ”. Denne graf er nyttig, når du gerne vil bestemme, hvordan din server udfører kontroldata til din disk. Dette kan være en god reference, hvis din transaktionslog (redo log eller ib_logfile0) er for stor. Denne graf er også en god indikator, hvis du skal justere variabler såsom innodb_log_file_size,, innodb_log_buffer_size, innodb_max_dirty_pages_pct eller innodb_adaptive_flushing_method. Jo tættere checkpoint-alderen er på den maksimale checkpoint-alder, jo mere fyldt er loggene, og InnoDB vil lave mere I/O for at bevare noget ledig plads i loggene. Checkpointing-mekanismen adskiller sig i subtile detaljer mellem Percona XtraDB-baserede smagsvarianter, MariaDB og Oracles version, du kan også finde forskelle i dens implementering mellem MySQL-versioner.

• InnoDB-transaktioner

  Når der er en stor transaktion i gang på din MySQL-server, er denne graf en god reference. Det vil tælle de transaktioner, der blev oprettet på et bestemt tidspunkt, og historiklængden (eller er faktisk historiklistens længde fundet i SHOW ENGINE INNODB STATUS) er antallet af sider i fortryd-loggen. De tendenser, du vil se her, er en god ressource til at tjekke, om det for eksempel kan betyde, at udrensning er forsinket på grund af en meget høj indsættelseshastighed for genindlæsning af data eller på grund af en langvarig transaktion, eller hvis udrensning simpelthen kan ikke følge med på grund af en høj disk I/O i volumen, hvor din $DATADIR ligger.

• Innodb Row Operations

  For visse DBA-opgaver vil du måske bestemme antallet af sletninger, indsættelser, læsninger og opdaterede rækker. Så er denne graf, hvad du kan bruge til at kontrollere disse.

• Innodb Row Lock Time

  Denne graf er en god ressource at se på, når du bemærker, at din applikation støder på mange hændelser for "Lås ventetimeout overskredet; prøv at genstarte transaktionen ”. Dette kan også hjælpe dig med at afgøre, om du måske har en indikation for at bruge dårlige forespørgsler om håndtering af låse. Dette er også en god reference at se på, når du optimerer dine forespørgsler, der involverer låsning af rækker. Hvis ventetiden er for lang, skal du tjekke den langsomme forespørgselslog eller køre en pt-query-digest og se, hvad det er for de mistænkte forespørgsler, der forårsager den opsvulmning i grafen.

  

• InnoDB I/O

  Når du vil bestemme mængden af ​​InnoDB-data, der læser, diskskyller, skriver og logskriver, har denne graf, hvad du skal se på. Du kan bruge denne graf til at afgøre, om dine InnoDB-variabler er godt indstillet til at håndtere dine specifikke krav. For eksempel, hvis du har Battery Backup Module cache, men du ikke får meget af dens optimale ydeevne, kan du stole på denne graf for at afgøre, om dine fsyncs() er højere end forventet. Så kan ændring af variablen innodb_flush_method og brug af O_DSYNC løse problemet.

• InnoDB-logfilbrug hver time

  Denne graf viser kun antallet af bytes skrevet til InnoDB-redo-logfilerne og væksten af ​​dine InnoDB-logfiler baseret på 24-timers tidsinterval for den aktuelle dato.

• InnoDB-logningsydelse

  Denne graf er tæt relateret til InnoDB Log File Usage Time-graf. Du skal bruge denne graf, når du skal bestemme, hvor stor din innodb_log_file_size skal være. Du kan bestemme antallet af bytes, der er skrevet til InnoDB-redo-logfilerne, og hvor effektivt din MySQL skyller data fra hukommelse til disk. Hver gang du oplever et lavt behov for at bruge din redo log plads, så ville det indikere, at du er nødt til at øge din innodb_log_file størrelse. I så fald vil denne graf fortælle dig, at du skal gøre det. Men for at grave mere ind i, hvor meget du skal bruge til din innodb_log_file, kan det være mere fornuftigt at tjekke LSN (Log Sequence Number) i SHOW ENGINE INNODB STATUS. Percona har en god blog relateret til dette, som er en god kilde at se på.

• InnoDB dødvande

  I visse situationer, hvor din applikationsklient ofte oplever deadlocks, eller du skal se på, hvor meget din MySQL oplever deadlocks, tjener denne graf formålet. Deadlocks indikerer, at du har et dårligt SQL-design, hvilket fører til, at dine transaktioner skaber en racetilstand, der forårsager deadlocks.

• Pushdown for indekstilstand

  Et lille advarselsord, når man ser på denne graf. Først skal du bestemme, at din MySQL globale variabel innodb_monitor_enable er indstillet til den korrekte værdi, der er modul_icp. Ellers vil du opleve et "Ingen datapunkter" som vist nedenfor:

  

  Grafens formål, hvis den har datapunkter defineret som det, jeg har i prøveudgangene, vil give en DBA et overblik over, hvor godt dine forespørgsler drager fordel af Index Condition Pushdown eller ICP for kort. ICP er en fantastisk funktion i MySQL, der tilbyder optimering af dine forespørgsler. I stedet for at MySQL læser de fulde rækker filtreret i dine WHERE-forespørgsler ved hentning, tilføjer den flere kontroller efter dine sekundære indekser. Dette tilføjer mere granularitet og sparer tid, ellers er motoren nødt til at læse hele tabelrækkerne i stedet, når den kun er baseret på det filtrerede indeks, og der ikke bruges nogen ICP. Dette undgår at læse de fulde rækker, der svarer til dine indekstupler, der matcher dine sekundære indekser.

  Lad mig uddybe lidt om denne graf, lad os sige, at jeg har en tabel ved navn:

  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)

  Og har nogle små 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 er aktiveret, er resultaterne mere effektive og gennemførlige:

  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)

  End uden 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)

  Dette er et simpelt eksempel på ICP, og hvordan denne graf kan gavne en DBA.

  

• InnoDB bufferpuljeindhold

  Når du arbejder med MySQL og bruger InnoDB-motor, er denne graf en af ​​de mest almindelige værdier (innodb_buffer_pool*), som du skal justere for at optimere MySQL-ydelsen. Specifikt hvad angår bufferpuljens indhold, viser den tendenserne for beskidte sider i forhold til det samlede bufferpuljeindhold. Det samlede bufferpuljeindhold inkluderer de rene sider bortset fra beskidte sider. Denne graf tjener sit formål ved at bestemme, hvor effektiv din MySQL håndterer bufferpuljen.

• InnoDB-bufferpuljesider

  Denne graf er nyttig, når du vil kontrollere, hvor effektiv MySQL bruger din InnoDB-bufferpulje. Du kan f.eks. bruge denne graf, hvis din daglige trafik ikke fylder den tildelte innodb_buffer_pool_size, så kan dette indikere, at visse dele af en applikation ikke er nyttige eller ikke tjener noget formål, eller hvis du indstiller innodb_buffer_pool_size meget højt hvilket kan være godt til at sænke værdien og genvinde plads tilbage til din hukommelse.

• InnoDB Buffer Pool I/O

  Når du skal kontrollere antallet af sider, der er oprettet og skrevet på InnoDB-tabeller, eller sidelæsninger til InnoDB-bufferpuljen ved handlinger på InnoDB-tabeller.

• InnoDB-bufferpuljeanmodninger

  Når du vil bestemme, hvor effektivt dine forespørgsler er ved at få adgang til InnoDB-bufferpuljen, tjener denne graf formålet. Denne graf viser tendenserne baseret på datapunkterne om, hvordan din MySQL-server fungerer, når InnoDB-motoren ofte skal have adgang til disken (indikation af, at bufferpuljen ikke er varmet op endnu), hvor hyppige bufferpuljenanmodningerne håndterede læseanmodninger og skriveanmodninger. anmodninger.

• InnoDB Read-Ahead

  Når du har variablen innodb_random_read_ahead sat til ON, så tilføj denne graf som en værdifuld trend at se på som en del af din DBA-rutine. Den viser tendenserne til, hvordan din MySQL InnoDB-lagringsmaskine administrerer bufferpuljen ved hjælp af read-ahead-baggrundstråden, hvordan den styrer dem, der efterfølgende bliver smidt ud uden at være blevet tilgået af forespørgsler, og hvordan starter InnoDB den tilfældige read-ahead, når en forespørgsel scanner en stor del af et bord, men i tilfældig rækkefølge.

  

• InnoDB Change Buffer

  Når du har Percona Server 5.7 kørende, er denne graf nyttig, når du overvåger, hvor godt InnoDB har allokeret ændringsbuffer. Disse ændringer inkluderer de indsættelser, opdateringer og sletninger, som er specificeret af variabelen innodb_change_buffering. Ændringsbuffer hjælper med at fremskynde forespørgsler og undgår betydelige I/O-tilfældig adgang, der ville være påkrævet for at indlæse sekundære indekssider fra disken.

• InnoDB Change Buffer Activity

  Dette er relateret til InnoDB Change Buffer-grafen, men dissekerer informationen i mere levedygtige datapunkter. Disse giver flere oplysninger for at overvåge, hvordan InnoDB håndterer ændringsbuffring. Dette er nyttigt i en bestemt DBA-opgave for at bestemme, om din innodb_change_buffer_max_size er sat til en for høj værdi, da ændringsbufferen deler den samme hukommelse som InnoDB-bufferpuljen, hvilket reducerer den tilgængelige hukommelse til cachedatasider. Du skal muligvis overveje at deaktivere ændringsbuffring, hvis arbejdssættet næsten passer ind i bufferpuljen, eller hvis dine tabeller har relativt få sekundære indekser. Husk, at ændringsbuffring ikke medfører ekstra overhead, fordi det kun gælder for sider, der ikke er i bufferpuljen. Denne graf er også nyttig, hvis du skal bestemme, hvordan sammenlægninger er nyttige, hvis du skal benchmarke din applikation baseret på bestemte anmodninger for bestemte scenarier. Lad os sige, at du har en masseindsættelse, du skal indstille innodb_change_buffering=insert og afgøre, om værdierne indstillet i din bufferpulje og innodb_change_buffer_max_size ikke påvirker disk I/O, især under gendannelse eller langsom nedlukning (nødvendigt, hvis du vil lave en failover med lavt nedetidskrav). Denne graf kan også tjene dit formål til at evaluere visse scenarier, da sammenlægning af ændringsbuffer kan tage flere timer, når der er adskillige sekundære indekser at opdatere og mange berørte rækker. I løbet af denne tid øges disk I/O, hvilket kan forårsage en betydelig opbremsning for diskbundne forespørgsler.

MySQL Performance Schema

MySQL Performance Schema er et kompliceret emne. Det er en lang og hård en, men jeg vil kun diskutere information, der er specifik for de grafer, vi har i SCUMM. Der er også visse variabler, som du skal overveje, og sikre, at de er indstillet korrekt. Sørg for, at du har din variabel innodb_monitor_enable =all og userstat=1 for at se datapunkter i dine grafer. Som en note, når jeg bruger ordet "begivenhed" her, betyder det ikke, at dette er relateret til MySQL Event Scheduler. Jeg taler om specifikke hændelser, såsom MySQL analyserer en forespørgsel, MySQL læser eller skriver til relæ/binær logfil osv.

Lad os så fortsætte med graferne.

• Performance Schema File IO (hændelser)

  Denne graf henter datapunkter, der er relateret til eventuelle hændelser, der fandt sted i MySQL, som kunne have været instrumenteret til at skabe flere forekomster af det instrumenterede objekt (f.eks. binære loglæsninger eller InnoDB-datafillæsninger). Hver række opsummerer begivenheder for et givet begivenhedsnavn. For eksempel, hvis der er et instrument til en mutex, der er oprettet for hver forbindelse, så kan der være mange forekomster af denne instrumenterede hændelse, da der er flere forbindelser. Opsummeringsrækken for instrumentet opsummerer alle disse tilfælde. Du kan tjekke disse hændelser i MySQL-manualen til oversigtstabeller for ydeevneskemaer for mere information.

• Performance Schema File IO (Load)

  Denne graf er den samme som "Performance Schema File IO (Events)"-grafen, bortset fra at den er instrumenteret baseret på belastningen.

• Performance Schema File IO (Bytes)

  Denne graf er den samme som "Performance Schema File IO (Events)" graf bortset fra, at den er instrumenteret baseret på størrelsen i bytes. For eksempel hvor lang tid tog en specifik hændelse, da MySQL udløste wait/io/file/innodb/innodb_data_file hændelse.

• Performance Schema Waits (Begivenheder)

  Denne graf har datagrafen for alle ventetider brugt på en specifik hændelse. Du kan tjekke oversigtstabeller for Vent begivenheder i manualen for mere information.

  

• Performance Schema Waits (Load)

  Samme som "Performance Schema Waits (Events)"-grafen, men denne gang viser den tendenserne for belastningen.

• Indeksadgangshandlinger (indlæs)

  Denne graf er en sammenlægning af alle tabelindeks I/O ventehændelser grupperet efter indeks(er) af en tabel, som genereret af wait/io/table/sql/handler-instrumentet. Du kan tjekke MySQL-manualen om Performance Schema-tabellen table_io_waits_summary_by_index_usage for mere information.

• Tabeladgangshandlinger (indlæs)

  "Samme som Index Access Operations (Load)"-grafen er en sammenlægning af alle tabel I/O-vent-hændelser gruppe for tabel, som genereret af wait/io/table/sql/handler-instrumentet. Dette er meget nyttigt for DBA'er. For eksempel vil du gerne spore, hvor hurtigt det tager at få adgang til (hente) eller opdatere (indsætte, slette, opdatere) en specifik tabel. Du kan se i MySQL-manualen om Performance Schema-tabellen table_io_waits_summary_by_table for at få flere oplysninger.

  

• Performance Schema SQL og eksterne låse (hændelser)

  Denne graf er en aggregering (tæller hvor mange gange det forekom) af alle tabellås-vent-hændelser, som genereret af wait/lock/table/sql/handler-instrumentet, som er gruppe for tabel. SQL-låsen her i grafen betyder de interne låse. Disse interne låse læses normalt, læses med delte låse, læse høj prioritet, læse ingen indsættelse, skrive tillad skrivning, skrive samtidig indsættelse, skrive forsinket, skrive lav prioritet, skrive normalt. Mens de eksterne låse læses eksternt og skrives eksternt. I enhver DBA-opgave er dette meget nyttigt, hvis du skal spore og undersøge låse på et bestemt bord, uanset dets type. Du kan tjekke tabellen table_lock_waits_summary_by_table for mere information.

• Performance Schema SQL og eksterne låse (sekunder)

  Samme som grafen "Performance Schema SQL &External Locks (Events)", men angivet i sekunder. Hvis du vil lede efter dine bordlåse baseret på sekunder, den holdt låsene, så er denne graf din gode ressource.

Konklusion

InnoDB Metrics og MySQL Performance Schema er nogle af de mest dybdegående og komplicerede dele i MySQL-domænet, især når der ikke er nogen visualisering til at hjælpe fortolkningen. Derfor kan det tage noget af din tid og hårde arbejde at gå til en manuel sporing og undersøgelser. SCUMM-dashboards tilbyder en meget effektiv og gennemførlig måde at håndtere disse på og sænke den ekstra belastning på enhver DBA-rutineopgave.

I denne blog lærte du, hvordan du bruger dashboards til InnoDB og Performance Schema til at forbedre databasens ydeevne. Disse dashboards kan gøre dig mere effektiv til at analysere ydeevne.