Tips för att leverera MySQL-databasprestanda - del två

Hantering av databasprestanda är ett område som företag när administratörer ofta tycker att de bidrar mer tid till än de förväntade sig.

Övervaka och reagera på problem med produktionsdatabasens prestanda är en av de mest kritiska uppgifterna inom ett databasadministratörsjobb. Det är en pågående process som kräver ständig vård. Applikationer och underliggande databaser utvecklas vanligtvis med tiden; växa i storlek, antal användare, arbetsbelastning, schemaändringar som kommer med kodändringar.

Långgående frågor är sällan oundvikliga i en MySQL-databas. Under vissa omständigheter kan en långvarig fråga vara en skadlig händelse. Om du bryr dig om din databas måste optimering av frågeprestanda och upptäcka långvariga frågor utföras regelbundet.

I den här bloggen kommer vi att ta en mer djupgående titt på den faktiska databasarbetsbelastningen, särskilt på sidan med körfrågor. Vi kommer att kontrollera hur man spårar frågor, vilken typ av information vi kan hitta i MySQL-metadata, vilka verktyg som ska användas för att analysera sådana frågor.

Hantera de långvariga frågorna

Låt oss börja med att kontrollera långvariga frågor. Först och främst måste vi känna till frågans karaktär, om det förväntas vara en lång eller kort pågående fråga. Vissa analys- och batchoperationer är tänkta att vara långvariga frågor, så vi kan hoppa över dem tills vidare. Beroende på tabellstorleken kan modifiering av tabellstrukturen med ALTER-kommandot vara en långvarig operation (särskilt i MySQL Galera Clusters).

• Tabelllås – Tabellen är låst av ett globalt lås eller explicit tabelllås när frågan försöker komma åt den.
• Ineffektiv fråga – Använd icke-indexerade kolumner när du söker eller går med, så MySQL tar längre tid att matcha villkoret.
• Deadlock - En fråga väntar på att få åtkomst till samma rader som är låsta av en annan begäran.
• Datauppsättningen passar inte in i RAM - Om din arbetsuppsättningsdata passar in i den cachen, kommer SELECT-frågor vanligtvis att vara relativt snabba.
• Suboptimala hårdvaruresurser – Detta kan vara långsamma diskar, RAID-ombyggnad, mättat nätverk, etc.

Om du ser att en fråga tar längre tid än vanligt att köra, undersök den.

Använda MySQL Show Process List

​MYSQL> SHOW PROCESSLIST;

Detta är vanligtvis det första du kör i fallet med prestandaproblem. SHOW PROCESSLIST är ett internt mysql-kommando som visar vilka trådar som körs. Du kan också se den här informationen från tabellen information_schema.PROCESSLIST eller kommandot mysqladmin process list. Om du har PROCESS-privilegiet kan du se alla trådar. Du kan se information som fråge-ID, exekveringstid, vem som kör den, klientvärden, etc. Informationen är lite försiktig beroende på MySQL-smaken och distributionen (Oracle, MariaDB, Percona)

SHOW PROCESSLIST;

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

| Id | User            | Host | db | Command | Time | State                  | Info | Progress |

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

|  2 | event_scheduler | localhost | NULL | Daemon  | 2693 | Waiting on empty queue | NULL   | 0.000 |

|  4 | root            | localhost | NULL | Query   | 0 | Table lock   | SHOW PROCESSLIST | 0.000 |

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

vi kan omedelbart se den stötande frågan direkt från utgången. I exemplet ovan kan det vara ett bordslås. Men hur ofta stirrar vi på dessa processer? Detta är bara användbart om du är medveten om den långvariga transaktionen. Annars skulle du inte veta förrän något händer - som att anslutningar hopar sig eller att servern blir långsammare än vanligt.

Använda MySQL Pt-query-digest

Om du vill se mer information om en viss arbetsbelastning använd pt-query-digest. Pt-query-digest är ett Linux-verktyg från Percona för att analysera MySQL-frågor. Det är en del av Percona Toolkit som du kan hitta här. Den stöder de mest populära 64-bitars Linux-distributionerna som Debian, Ubuntu och Redhat.

För att installera det måste du konfigurera Percona repositories och sedan installera paketet perona-toolkit.

Installera Percona Toolkit med din pakethanterare:

Debian eller Ubuntu:

sudo apt-get install percona-toolkit

RHEL eller CentOS:

sudo yum install percona-toolkit

Pt-query-digest accepterar data från processlistan, generell logg, binär logg, långsam logg eller tcpdump. Utöver det är det möjligt att polla MySQL processlistan med ett definierat intervall - en process som kan vara resurskrävande och långt ifrån idealiska, men som ändå kan användas som ett alternativ.

Den vanligaste källan för pt-query-digest är en långsam frågelogg. Du kan styra hur mycket data som ska gå dit med parametern log_slow_verbosity.

Det finns ett antal saker som kan göra att en fråga tar längre tid att köra:

• mikrotid - frågor med mikrosekundsprecision.
• query_plan - information om frågans exekveringsplan.
• innodb  - InnoDB-statistik.
• minimal – Motsvarar att bara aktivera mikrotid.
• standard - Motsvarar att aktivera mikrotid,innodb.
• full – Motsvarar alla andra värden ELLER läggs ihop utan alternativen för profilering och profiling_use_getrusage.
• profilering – Möjliggör profilering av alla frågor i alla anslutningar.
• profiling_use_getrusage - Möjliggör användning av getrusage-funktionen.

källa:Percona-dokumentation

För fullständighetens skull använd log_slow_verbosity=full vilket är ett vanligt fall.

Långsam frågelogg

Den långsamma frågeloggen kan användas för att hitta frågor som tar lång tid att köra och därför är kandidater för optimering. Långsam frågelogg fångar långsamma frågor (SQL-satser som tar mer än long_query_time sekunder att köra), eller frågor som inte använder index för uppslagningar (log_queries_not_using_indexes). Den här funktionen är inte aktiverad som standard och för att aktivera den ställer du bara in följande rader och startar om MySQL-servern:

[mysqld]
slow_query_log=1
log_queries_not_using_indexes=1
long_query_time=0.1

Den långsamma frågeloggen kan användas för att hitta frågor som tar lång tid att köra och därför är kandidater för optimering. Men att undersöka en lång långsam frågelogg kan vara en tidskrävande uppgift. Det finns verktyg för att analysera MySQL långsamma frågeloggfiler och sammanfatta deras innehåll som mysqldumpslow, pt-query-digest.

Prestandaschema

Prestandaschema är ett utmärkt verktyg tillgängligt för att övervaka MySQL-serverns interna funktioner och exekveringsdetaljer på en lägre nivå. Den hade ett dåligt rykte i en tidig version (5.6) eftersom aktivering av den ofta orsakade prestandaproblem, men de senaste versionerna skadar inte prestandan. Följande tabeller i Performance Schema kan användas för att hitta långsamma frågor:

• 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 och senare inkluderar sys-schemat, en uppsättning objekt som hjälper DBA:er och utvecklare att tolka data som samlas in av Performance Schema till en mer lättförståelig form. Sys-schemaobjekt kan användas för typiska justeringar och diagnoser.

Nätverksspårning

Vad händer om vi inte har tillgång till frågeloggen eller direkta programloggar. I så fall kan vi använda en kombination av tcpdump och pt-query digest som kan hjälpa till att fånga frågor.

$ tcpdump -s 65535 -x -nn -q -tttt -i any port 3306 > mysql.tcp.txt

När insamlingsprocessen är slut kan vi fortsätta med att bearbeta data:

$ pt-query-digest --limit=100% --type tcpdump mysql.tcp.txt > ptqd_tcp.out

ClusterControl Query Monitor

ClusterControl Query Monitor är en modul i en klusterkontroll som tillhandahåller kombinerad information om databasaktivitet. Den kan samla in information från flera källor som att visa processlista eller långsam frågelogg och presentera den på ett föraggregerat sätt.

SQL-övervakningen är uppdelad i tre sektioner.

Bästa frågorna

presenterar information om frågor som kräver en betydande del av resurser.

Kör frågor

det är en processlista med information kombinerad från alla databasklusternoder till en vy. Du kan använda det för att döda frågor som påverkar din databasoperationer.

Frågeoutliers

presentera listan över frågor med exekveringstid längre än genomsnittet.

Slutsats

Detta är allt för del två. Den här bloggen är inte avsedd att vara en uttömmande guide till hur man förbättrar databasprestanda, men den ger förhoppningsvis en tydligare bild av vilka saker som kan bli väsentliga och några av de grundläggande parametrarna som kan konfigureras. Tveka inte att meddela oss om vi har missat några viktiga i kommentarerna nedan.