MySQL-prestaties:lange zoekopdrachten identificeren

Elke door MySQL ondersteunde toepassing kan profiteren van een nauwkeurig afgestemde databaseserver. Het Liquid Web Heroic Support-team is in de loop der jaren talloze situaties tegengekomen waarin enkele kleine aanpassingen een wereld van verschil hebben gemaakt in de prestaties van de website en de applicatie. In deze serie artikelen hebben we enkele van de meest voorkomende aanbevelingen uiteengezet die de grootste impact hebben gehad op de prestaties.

Preflightcontrole

Dit artikel is van toepassing op de meeste op Linux gebaseerde MySQL VPS-servers. Dit omvat, maar is niet beperkt tot, zowel traditionele dedicated als Cloud VPS-servers met een verscheidenheid aan algemene Linux-distributies. Het artikel kan worden gebruikt met de volgende typen Liquid Web-systemen:

• Core-managed CentOS 6x/7x
• Kernbeheerde Ubuntu 14.04/16.04
• Volledig beheerde CentOS 6/7 cPanel
• Volledig beheerde CentOS 7 Plesk Onyx 17
• Zelfbeheerde Linux-servers

Deze serie artikelen veronderstelt bekendheid met de volgende basisconcepten voor systeembeheer:

• SSH-verbindingen en basisnavigatie van de standaard Linux-opdrachtregel-shellomgeving.
• Bestanden openen, bewerken en opslaan in Vim of een gekozen systeemeditor.
• Interactieve MySQL-modus en algemene MySQL-querysyntaxis.

Wat is MySQL-optimalisatie?

Er is geen duidelijk gedefinieerde definitie voor de term MySQL-optimalisatie. Het kan iets anders betekenen, afhankelijk van de persoon, beheerder, groep of bedrijf. Voor deze serie artikelen over MySQL-optimalisatie definiëren we MySQL-optimalisatie als: De configuratie van een MySQL- of MariaDB-server die is geconfigureerd om veelvoorkomende knelpunten te voorkomen die in deze serie artikelen worden besproken.

Wat is een knelpunt?

Zeer vergelijkbaar met de hals van een frisdrankfles, is een knelpunt als technische term een ​​punt in een applicatie- of serverconfiguratie waar een kleine hoeveelheid verkeer of data probleemloos kan passeren. Een groter volume van hetzelfde type verkeer of data wordt echter belemmerd of geblokkeerd en kan niet succesvol werken zoals het is. Zie het volgende voorbeeld van een configuratieknelpunt:

In dit voorbeeld kan de server 10 verbindingen tegelijk afhandelen. De configuratie accepteert echter slechts 5 verbindingen. Dit probleem zou zich niet voordoen zolang er 5 of minder verbindingen tegelijk waren. Wanneer het verkeer echter oploopt tot 10 verbindingen, begint de helft te mislukken vanwege ongebruikte bronnen in de serverconfiguratie. De bovenstaande voorbeelden illustreren de vorm van het knelpunt waar het zijn naam aan ontleent versus een geoptimaliseerde configuratie die het knelpunt corrigeert.

Wanneer moet ik mijn MySQL-database optimaliseren?

Idealiter zou het afstemmen van de databaseprestaties regelmatig moeten plaatsvinden en voordat de productiviteit wordt aangetast. Het is een goede gewoonte om wekelijkse of maandelijkse controles van de databaseprestaties uit te voeren om te voorkomen dat problemen een negatieve invloed hebben op applicaties. De meest voor de hand liggende symptomen van prestatieproblemen zijn:

• Query's stapelen zich op en worden nooit voltooid in de MySQL-procestabel.
• Applicaties of websites die de database gebruiken, worden traag.
• Verbindingstime-outs, vooral tijdens piekuren.

Hoewel het normaal is dat er meerdere gelijktijdige query's tegelijk worden uitgevoerd op een druk systeem, wordt het een probleem wanneer deze query's er te lang over doen om regelmatig te worden voltooid. Hoewel de specifieke drempel verschilt per systeem en per applicatie, zal een gemiddelde querytijd van meer dan enkele seconden zich manifesteren als een vertraging van aangesloten websites en applicaties. Deze vertragingen kunnen soms klein beginnen en onopgemerkt blijven totdat een grote verkeerstoename een bepaald knelpunt bereikt.

Prestatieproblemen identificeren

Weten hoe u de MySQL-procestabel moet onderzoeken, is van vitaal belang voor het diagnosticeren van de specifieke bottleneck die wordt aangetroffen. Er zijn een aantal manieren om de procestabel te bekijken, afhankelijk van uw specifieke server en voorkeur. Kortheidshalve zal deze serie zich richten op de meest gebruikte methoden via Secure Shell (SSH) toegang:

Methode 1. De MySQL-procestabel gebruiken

Gebruik de 'mysqladmin ’ opdrachtregelprogramma met de vlag ‘proceslijst ’ of ‘proc ' in het kort. (Toevoegen van de vlag 'statistieken ’ of ‘statistiek ’ in het kort toont lopende statistieken voor zoekopdrachten sinds de laatste herstart van MySQL.)

Commando:

mysqladmin proc stat

Uitgang:

 +-------+------+-----------+-----------+---------+------+-------+
 | 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

Methode 2:De MySQL-procestabel gebruiken

Voer de 'show processlist;'-query uit vanuit de MySQL-prompt in de interactieve modus. (Eenhet toevoegen van de ' vol ’  modifier van de opdracht schakelt het afkappen van de . uit Info kolom. Dit is nodig bij het bekijken van lange zoekopdrachten.)

Commando:

show processlist;

Uitgang:

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 |
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+

Het logbestand voor trage zoekopdrachten gebruiken

Een ander waardevol hulpmiddel in  MySQL is de meegeleverde functie voor langzame logboekregistratie van zoekopdrachten. Deze functie is de geprefereerde methode om regelmatig langlopende zoekopdrachten te vinden. Er zijn verschillende richtlijnen beschikbaar om deze functie aan te passen. De meest benodigde instellingen zijn echter:

Deze richtlijnen worden ingesteld in de sectie [mysqld] van het MySQL-configuratiebestand in /etc/my.cnf en vereisen een herstart van de MySQL-service voordat ze van kracht worden. Zie onderstaand voorbeeld voor opmaak:

[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

Zodra het logbestand voor langzame query's is ingeschakeld, moet u er regelmatig een follow-up mee doen om onhandelbare query's te bekijken die moeten worden aangepast voor betere prestaties. Om het logbestand met trage query's te analyseren, kunt u het rechtstreeks ontleden om de inhoud ervan te bekijken. Het volgende voorbeeld toont de statistieken voor de voorbeeldquery die langer duurde dan de geconfigureerde 5 seconden:

# 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();

Optioneel kunt u de opdrachtregeltool mysqldumpslow gebruiken, die het logbestand voor langzame query's en groepen zoals query's samen ontleedt, behalve waarden van getal en tekenreeksgegevens:

~ $ 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()

(Ga voor gebruiksinformatie naar de MySQL-documentatie hier - mysqldumpslow — Vat trage query-logbestanden samen)

Conclusie

Zo besluit het eerste deel van onze Database Optimization-serie en geeft ons een solide basis om naar te verwijzen voor benchmarkdoeleinden. Hoewel databaseproblemen ingewikkeld kunnen zijn, zal onze serie deze concepten opsplitsen om middelen te bieden om uw database te optimaliseren door middel van databaseconversie, tabelconversie en indexering.

Hoe kunnen we helpen?

We zijn er trots op de meest behulpzame mensen in Hosting™ te zijn!

Onze ondersteuningsteams zijn gevuld met ervaren Linux-technici en getalenteerde systeembeheerders die een grondige kennis hebben van meerdere webhostingtechnologieën, vooral de technologieën die in dit artikel worden besproken.

Mocht u vragen hebben over deze informatie, dan zijn wij altijd beschikbaar om al uw vragen met betrekking tot dit artikel te beantwoorden, 24 uur per dag, 7 dagen per week 365 dagen per jaar.

Als u een volledig beheerde VPS-server, Cloud Dedicated, VMWare Private Cloud, Private Parent-server, Managed Cloud Servers of een Dedicated server-eigenaar bent en u zich niet op uw gemak voelt bij het uitvoeren van een van de beschreven stappen, is telefonisch bereikbaar op @800.580.4985, een chat- of supportticket om u bij dit proces te helpen.