MySQL-prestanda:Identifiera långa frågor

Varje MySQL-stödd applikation kan dra nytta av en finjusterad databasserver. Liquid Web Heroic Support-teamet har stött på många situationer under åren då några mindre justeringar har gjort en värld av skillnad i webbplats- och applikationsprestanda. I den här artikelserien har vi beskrivit några av de vanligare rekommendationerna som har haft störst inverkan på prestanda.

Preflight Check

Den här artikeln gäller de flesta Linux-baserade MySQL VPS-servrar. Detta inkluderar, men är inte begränsat till, både traditionella dedikerade och Cloud VPS-servrar som kör en mängd vanliga Linux-distributioner. Artikeln kan användas med följande Liquid Web-systemtyper:

• Core-managed CentOS 6x/7x
• Kärnhanterad Ubuntu 14.04/16.04
• Fullständigt hanterad CentOS 6/7 cPanel
• Fullt hanterad CentOS 7 Plesk Onyx 17
• Självhanterade Linux-servrar

Denna artikelserie förutsätter bekantskap med följande grundläggande systemadministrationskoncept:

• SSH-anslutningar och grundläggande navigering i Linux-kommandoradsskalmiljön.
• Öppna, redigera och spara filer i Vim eller en vald systemredigerare.
• MySQL interaktivt läge och allmän MySQL-frågesyntax.

Vad är MySQL-optimering?

Det finns ingen tydlig definition för begreppet MySQL-optimering. Det kan betyda olika beroende på person,  administratör, grupp eller företag. För den här serien av artiklar om MySQL-optimering kommer vi att definiera MySQL-optimering som: Konfigurationen av en MySQL- eller MariaDB-server som har konfigurerats för att undvika vanliga flaskhalsar som diskuteras i den här artikelserien.

Vad är en flaskhals?

Mycket lik halsen på en läskflaska, en flaskhals som teknisk term är en punkt i en applikations- eller serverkonfiguration där en liten mängd trafik eller data kan passera utan problem. Men en större volym av samma typ av trafik eller data hindras eller blockeras och kan inte fungera som den är. Se följande exempel på en konfigurationsflaskhals:

I det här exemplet kan servern hantera 10 anslutningar samtidigt. Konfigurationen accepterar dock endast 5 anslutningar. Detta problem skulle inte visa sig så länge det fanns 5 eller färre anslutningar samtidigt. Men när trafiken ökar upp till 10 anslutningar börjar hälften av dem misslyckas på grund av oanvända resurser i serverkonfigurationen. Ovanstående exempel illustrerar flaskhalsformen där den får sitt namn kontra en optimerad konfiguration som korrigerar flaskhalsen.

När ska jag optimera min MySQL-databas?

Helst bör inställning av databasprestanda ske regelbundet och innan produktiviteten påverkas. Det är bästa praxis att utföra veckovisa eller månatliga granskningar av databasprestanda för att förhindra att problem påverkar applikationer negativt. De mest uppenbara symptomen på prestationsproblem är:

• Frågor staplas och slutförs aldrig i MySQL-processtabellen.
• Applikationer eller webbplatser som använder databasen blir tröga.
• Timeoutfel för anslutning, särskilt under rusningstid.

Även om det är normalt att det finns flera samtidiga frågor som körs samtidigt på ett upptaget system, blir det ett problem när dessa frågor tar för lång tid att avsluta regelbundet. Även om den specifika tröskeln varierar per system och per applikation, kommer genomsnittliga frågetider som överstiger flera sekunder att visa sig som en avmattning på bifogade webbplatser och applikationer. Dessa avmattningar kan ibland börja i det små och gå obemärkt förbi tills en stor trafikökning träffar en viss flaskhals.

Identifiera prestandaproblem

Att veta hur man undersöker MySQL-procestabellen är avgörande för att diagnostisera den specifika flaskhalsen som man stöter på. Det finns ett antal sätt att visa processtabellen beroende på din specifika server och preferenser. För korthetens skull kommer denna serie att fokusera på de vanligaste metoderna som används via Secure Shell (SSH) åtkomst:

Metod 1. Använda MySQL Process Table

Använd 'mysqladmin ' kommandoradsverktyg med flaggan 'processlist ' eller 'proc ' för korta. (Lägger till flaggan "statistik ' eller 'stat ’ kommer kort att visa löpande statistik för frågor sedan MySQL:s senaste omstart.)

Kommando:

mysqladmin proc stat

Utdata:

 +-------+------+-----------+-----------+---------+------+-------+
 | Id    | User | Host      | db        | Command | Time | State | Info               | Progress |
 +-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
 | 77255 | root | localhost | employees | Query   | 150  |       | call While_Loop2() | 0.000    |
 | 77285 | root | localhost |           | Query   | 0    | init  | show processlist   | 0.000    |
 +-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
 Uptime: 861755  Threads: 2  Questions: 20961045  Slow queries: 0  Opens: 2976  Flush tables: 1  Open tables: 1011  Queries per second avg: 24.323

Metod 2:Använda MySQL Process Table

Kör "visa processlista;"-frågan från MySQL interaktivt lägesuppmaning. (Alägga på " full ’  modifierare till kommandot inaktiverar trunkering av Information kolumn. Detta är nödvändigt när du visar långa frågor.)

Kommando:

show processlist;

Utdata:

MariaDB [(none)]> show full processlist;
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
 | Id    | User | Host      | db        | Command | Time | State | Info                  | Progress |
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
 | 77006 | root | localhost | employees | Query   |  151 | NULL  | call While_Loop2()    |    0.000 |
 | 77021 | root | localhost | NULL      | Query   |    0 | init  | show full processlist |    0.000 |
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+

Använda den långsamma frågeloggen

Ett annat värdefullt verktyg i  MySQL är den inkluderade funktionen för långsam frågeloggning. Den här funktionen är den föredragna metoden för att regelbundet hitta långvariga frågor. Det finns flera direktiv tillgängliga för att justera denna funktion. De vanligaste inställningarna är dock:

Dessa direktiv finns i avsnittet [mysqld] i MySQL-konfigurationsfilen som finns på /etc/my.cnf och kommer att kräva en omstart av MySQL-tjänsten innan de träder i kraft. Se exemplet nedan för formatering:

[mysqld]
 log-error=/var/lib/mysql/mysql.err
 innodb_file_per_table=1
 default-storage-engine=innodb
 innodb_buffer_pool_size=128M
 innodb_log_file_size=128M
 max_connections=300
 key_buffer_size = 8M
 slow_query_log=1
 slow_query_log_file=/var/lib/mysql/slowquery.log
 long_query_time=5

När den långsamma frågeloggen är aktiverad måste du regelbundet följa upp den för att granska oregerliga frågor som måste justeras för bättre prestanda. För att analysera den långsamma frågeloggfilen kan du analysera den direkt för att granska dess innehåll. Följande exempel visar statistiken för exempelfrågan som löpte längre än de konfigurerade 5 sekunderna:

# Time: 180717  0:23:28
 # User@Host: root[root] @ localhost []
 # Thread_id: 32  Schema: employees  QC_hit: No
 # Query_time: 627.163085  Lock_time: 0.000021  Rows_sent: 0  Rows_examined: 0
 # Rows_affected: 0
 use employees;
 SET timestamp=1531801408;
 call While_Loop2();

Alternativt kan du använda kommandoradsverktyget mysqldumpslow, som analyserar den långsamma frågeloggfilen och grupperar som frågor tillsammans utom värden för nummer och strängdata:

~ $ mysqldumpslow -a /var/lib/mysql/slowquery.log
 Reading mysql slow query log from /var/lib/mysql/slowquery.log
 Count: 2  Time=316.67s (633s)  Lock=0.00s (0s)  Rows_sent=0.5 (1), Rows_examined=0.0 (0), Rows_affected=0.0 (0), root[root]@localhost
 call While_Loop2()

(För användningsinformation besök MySQL-dokumentationen här - mysqldumpslow — Sammanfatta långsamma frågeloggfiler)

Slutsats

Så avslutar den första delen av vår databasoptimeringsserie och ger oss en solid grund att referera till för benchmarksyften. Även om databasproblem kan vara komplicerade, kommer vår serie att dela upp dessa begrepp för att ge möjlighet att optimera din databas genom databaskonvertering, tabellkonvertering och indexering.

Hur kan vi hjälpa till?

Vi är stolta över att vara de mest hjälpsamma människorna inom Hosting™!

Våra supportteam är fyllda med erfarna Linux-tekniker och duktiga systemadministratörer som har ingående kunskap om flera webbhotelltekniker, särskilt de som diskuteras i den här artikeln.

Om du har några frågor angående denna information, är vi alltid tillgängliga för att svara på alla frågor som rör denna artikel, 24 timmar om dygnet, 7 dagar i veckan 365 dagar om året.

Om du är en helt hanterad VPS-server, Cloud Dedicated, VMWare Private Cloud, Private Parent Server, Managed Cloud Servers eller en dedikerad serverägare och du är obekväm med att utföra något av stegen som beskrivs, vi kan nås via telefon på @800.580.4985, en chatt eller supportbiljett för att hjälpa dig med denna process.