Hem › Utbildning › Profileringsfrågor i MySQL. Vad är "serverloggar", hur man visar Mysql-serverloggar, frågeloggar

Profileringsfrågor i MySQL. Vad är "serverloggar", hur man visar Mysql-serverloggar, frågeloggar

MySQL-frågeprofilering är en användbar teknik för att analysera den övergripande prestandan för databasbaserade applikationer. När man utvecklar medelstora till stora applikationer finns det vanligtvis hundratals frågor spridda över en stor kodbas, och databasen bearbetar många frågor per sekund. Utan frågeprofilering blir det mycket svårt att fastställa platsen och orsakerna till förekomsten flaskhalsar applikationer. Denna handledning beskriver några användbara frågeprofileringstekniker med hjälp av MySQL:s inbyggda verktyg.

MySQL långsam frågelogg

MySQL långsamma frågelogg (eller långsam frågelogg) är en logg där MySQL skickar långsamma och potentiellt problematiska frågor.

Den här funktionen kommer med MySQL men är inaktiverad som standard. MySQL bestämmer vilka frågor som ska inkluderas i den här loggen med hjälp av speciella variabler som gör att du kan profilera frågan baserat på applikationens prestandakrav. Vanligtvis läggs frågor som tar längre tid att bearbeta och frågor som har felaktiga index in i den här loggen.

Profileringsvariabler

De grundläggande servervariablerna för att konfigurera MySQL långsamma frågelogg är:

slow_query_log global
slow_query_log_file global
long_query_time global/session
log_queries_not_using_indexes global
min_examined_row_limit global/session

slow_query_log – en logisk variabel för att aktivera eller inaktivera den långsamma frågeloggen.

slow_query_log_file – den absoluta sökvägen till frågeloggfilen. Filkatalogen måste ägas av mysqld-användaren och ha lämpliga läs- och skrivbehörigheter. Mysql-demonen kommer troligen att startas som mysql, men för att vara säker, kör kommandot i en Linux-terminal:

ps -ef | grep bin/mysqld | skär -d" " -f1

Utdata kommer att visa den aktuella användaren och mysqld-användaren.

cd /var/log
mkdir mysql
chmod 755 mysql
chown mysql:mysql mysql

long_query_time – tid i sekunder för att kontrollera frågelängden. Om värdet är 5 loggas alla förfrågningar som tar mer än 5 sekunder att behandla.
log_queries_not_using_indexes – Ett booleskt värde som avgör om frågor som inte använder index ska loggas. När man analyserar är sådana frågor viktiga.
min_examined_row_limit – definierar det minsta antalet rader som ska analyseras. Med ett värde på 1000 ignoreras alla frågor som analyserar färre än 1000 rader.

MySQL-servervariabler kan ställas in i MySQL-konfigurationsfilen eller dynamiskt med hjälp av användargränssnitt eller MySQL-kommandoraden. Om variabler ställs in i konfigurationsfilen kommer de att finnas kvar när servern startas om, men servern måste startas om för att aktivera dem. MySQL-konfigurationsfilen finns vanligtvis i /etc/my.cnf eller /etc/mysql/my.cnf. För att hitta konfigurationsfilen anger du (du kan behöva utöka din sökning till andra rotkataloger):

hitta /etc -name my.cnf
hitta /usr -name my.cnf

När du har hittat konfigurationsfilen lägger du till de nödvändiga variablerna i avsnittet:

….
slow-query-log = 1
slow-query-log-file = /var/log/mysql/localhost-slow.log
long_query_time = 1
log-queries-not-använder-index

För att ändringarna ska träda i kraft måste du starta om servern. Om ändringar behöver aktiveras omedelbart, ställ in variablerna dynamiskt:

mysql> SET GLOBAL slow_query_log = "PÅ";
mysql> SET GLOBAL slow_query_log_file = "/var/log/mysql/localhost-slow.log";
mysql> SET GLOBAL log_queries_not_using_indexes = "PÅ";
mysql> SET SESSION long_query_time = 1;
mysql> SET SESSION min_examined_row_limit = 100;

Så här kontrollerar du variabelvärden:

mysql> VISA GLOBALA VARIABLER SOM "slow_query_log";
mysql> VISA SESSIONSVARIABLER SOM "long_query_time";

En av nackdelarna med att dynamiskt ändra MySQL-variabler är att variablerna kommer att gå förlorade när servern startas om. Därför bör alla viktiga variabler som behöver sparas läggas till i filen.

Generera en profileringsfråga

Nu är du bekant med inställningarna för långsamma frågeloggar. Försök att generera frågedata för profilering.

Notera: Exemplet som ges här kördes på en körande MySQL-instans utan att några långsamma frågeloggar konfigurerats. Dessa testfrågor kan köras via GUI eller kommandorad MySQL.

När du övervakar loggen över långsamma förfrågningar är det användbart att öppna två terminalfönster: en anslutning för sändning MySQL-uttalanden, och den andra är för att visa förfrågningsloggen.

Logga in på MySQL-servern med konsolen som användare med SUPER ADMIN-behörighet. För att komma igång, skapa en testdatabas och tabell, lägg till dummydata till den och aktivera långsam frågeloggning.

Notera: Helst körs det här exemplet bäst i en miljö utan några andra applikationer som använder MySQL för att undvika att frågeloggen blir rörig.

$> mysql -u -s
mysql> CREATE DATABASE profile_sampling;

mysql> ANVÄND profile_sampling;

mysql> CREATE TABLE-användare (id TINYINT PRIMARY KEY AUTO_INCREMENT, namn VARCHAR(255));

mysql> INSERT INTO users (namn) VÄRDEN ("Walter"),("Skyler"),("Jesse"),("Hank"),("Walter Jr."),("Marie"),("Saul") "),("Gustavo"),("Hector"),("Mike");

mysql> SET GLOBAL slow_query_log = 1;

mysql> SET GLOBAL slow_query_log_file = "/var/log/mysql/localhost-slow.log";

mysql> SET GLOBAL log_queries_not_using_indexes = 1;

mysql> SET long_query_time = 10;

mysql> SET min_examined_row_limit = 0;

Nu har du en testdatabas och en tabell med lite data. Långsam frågelogg är aktiverad. Vi ställde medvetet in bearbetningstiden för begäran till hög och inaktiverade radräkningskontrollen. För att se loggen, skriv in:

cd /var/log/mysql
ls -l

För närvarande bör det inte finnas en logg över långsamma förfrågningar i mappen, eftersom det här ögonblicket det fanns inga förfrågningar. Om en sådan logg redan finns betyder det att databasen redan har stött på långsamma frågor sedan du aktiverade stöd för den långsamma frågeloggen. Detta kan förvränga resultatet av detta exempel. Gå tillbaka till MySQL-fliken och kör:

mysql> ANVÄND profile_sampling;
mysql> SELECT * FROM användare WHERE id = 1;

Den körda frågan hämtar helt enkelt data och använder indexet för den första nyckeln från tabellen. Den här frågan var snabb och använde ett index, så den registreras inte i den långsamma frågeloggen. Gå tillbaka till katalogen och se till att ingen frågelogg har skapats. Gå nu tillbaka till MySQL-fönstret och kör:

mysql>

Den här frågan använder inget index. Något liknande bör nu visas i loggen /var/log/mysql/localhost-slow.log:

# Tid: 140322 13:54:58

använd profile_sampling;
SET timestamp=1395521698;

Ännu ett exempel. Öka det minsta antalet rader att tolka och skicka en begäran så här:

mysql> SET min_examined_row_limit = 100;
mysql> SELECT * FROM användare WHERE name = "Walter";

Data kommer inte att läggas till i loggen eftersom färre än 100 rader analyserades under begäran.

Notera: Om data inte har lagts till i loggen måste du kontrollera flera faktorer. Kontrollera först behörigheterna för katalogen där loggen skapas. Den måste ägas av mysqld-användaren/gruppen och ha chmod 755-privilegier. Du bör sedan kontrollera om det finns andra långsamma frågeinställningar på servern som åsidosätter dina inställningar. Återställ standardinställningarna för att ta bort alla långsamma begärandevariabler från konfigurationsfilen och starta om servern. Du kan också dynamiskt ställa in globala variabler till deras standardvärden. Om du gör ändringar dynamiskt, logga ut och logga in på MySQL igen för att uppdatera inställningarna.

Analysera frågeprofileringsdata

Tänk på följande data:

# Tid: 140322 13:54:58
#User@Host: root@localhost
# Fråga_tid: 0,000303 Lås_tid: 0,000090 Rader_sänt: 1 Rader_undersökta: 10
använd profile_sampling;
SET timestamp=1395521698;
SELECT * FROM användare WHERE name = "Jesse";

Denna post visar:

Utförandetid för fråga
Vem skickade den
Hur lång tid tog det att behandla begäran?
Längd
Hur många rader som returnerades
Hur många rader analyserades

Detta är användbart eftersom varje begäran som bryter mot prestandakraven som anges i variablerna hamnar i loggen. Detta gör att en utvecklare eller administratör snabbt kan spåra förfrågningar som inte fungerar. Dessutom kan frågeprofileringsdata hjälpa dig att avgöra vilka omständigheter som gör att din applikation fungerar dåligt.

Använder mysqldumpslow

Profilering kan inkluderas i databasbaserade applikationer för att säkerställa måttligt dataflöde.

När loggstorleken växer blir det svårt att analysera all data, och problematiska frågor kan lätt gå vilse i den. MySQL erbjuder ett verktyg som heter mysqldumpslow, som hjälper till att undvika detta problem genom att dela upp loggen över långsamma frågor. Binären är länkad till MySQL (på Linux), så du kan helt enkelt köra kommandot:

mysqldumpslow -t 5 -s på /var/log/mysql/localhost-slow.log

Kommandot kan acceptera olika parametrar för att anpassa dess utdata. Ovanstående exempel visar de 5 bästa förfrågningarna sorterade efter genomsnittlig förfrågningstid. Sådana strängar är mer läsbara och grupperas också efter begäran.

Antal: 2 Tid=68,34s (136s) Lås=0,00s (0s) Rader=39892974,5 (79785949), root@localhost
VÄLJ PL.pl_title, P.page_title
FRÅN sida P
INNER JOIN sidlänkar PL
PÅ PL.pl_namespace = P.page_namespace
WHERE P.page_namespace = N
…

Utgången visar följande data:

Antal: hur många gånger förfrågan loggades.
Tid: genomsnittlig och total förfråganstid (inom parentes).
Lås: bordslåstid.
Rader: Antalet rader som returneras.

Kommandot utesluter numeriska och strängvärden, så identiska frågor med olika WHERE-villkor behandlas som samma. Mysqldumpslow-verktyget eliminerar behovet av att ständigt granska loggen över långsamma frågor, istället låter dig utföra regelbundna automatiska kontroller. Kommandoalternativen mysqldumpslow låter dig köra komplexa uttryck.

Begär uppdelning

Ett annat profileringsverktyg att tänka på är Complex Query Breakdown Tool. Det låter dig identifiera problematiska frågor i den långsamma frågeloggen och köra den i MySQL. Först måste du aktivera profilering och sedan köra frågan:

mysql> SET SESSION-profilering = 1;
mysql> ANVÄND profile_sampling;
mysql> SELECT * FROM användare WHERE name = "Jesse";
mysql> VISA PROFILER;

När profilering är aktiverad visar SHOW PROFILES en tabell som associerar Query_ID med SQL-uttrycket. Hitta Query_ID som motsvarar den pågående frågan och kör följande fråga (ersätt # med ditt Query_ID):

mysql> SELECT * FROM INFORMATION_SCHEMA.PROFILING WHERE QUERY_ID=#;

Kommandot returnerar en tabell:

SEQ	STAT	VARAKTIGHET
1	startande	0.000046
2	kontrollera behörigheter	0.000005
3	öppna bord	0.000036
…	…	…

STATE är ett steg i frågekörningsprocessen och DURATION är den tid det tar att slutföra det steget på några sekunder. Det är inte särskilt mycket användbart verktyg, men det kan hjälpa till att avgöra vilken del av frågekörningen som orsakar mest latens.

Notera Obs: Detta verktyg bör inte användas i en produktionsmiljö.

Långsam frågeloggprestanda

Allt som återstår är att ta reda på hur den långsamma frågeloggen påverkar prestandan. I allmänhet är det säkert att köra långsamma frågeloggar i en produktionsmiljö; Varken CPU eller I/O ska påverkas. Du bör dock ha en strategi för att övervaka loggstorleken för att säkerställa att loggen inte blir för stor för filsystem. När du kör en långsam frågelogg i en produktionsmiljö bör du dessutom ställa in long_query_time till 1 eller högre.

Slutsats

En långsam frågelogg kan hjälpa dig att identifiera problematiska frågor och utvärdera övergripande frågeprestanda. Samtidigt kan utvecklaren få en detaljerad förståelse för hur applikationen fungerar MySQL-frågor. Verktyget mysqldumpslow låter dig hantera långsamma frågeloggar och enkelt införliva dem i din utvecklingsprocess. Genom att identifiera problematiska frågor kan du optimera frågebehandlingen för att förbättra prestandan.

Taggar:

Händelseloggar är det första och enklaste verktyget för att fastställa systemstatus och identifiera fel. Det finns fyra huvudloggar i MySQL:

Felloggen— standardfellogg som samlas in medan servern körs (inklusive start och stopp);
Binär logg— En logg över alla databasmodifieringskommandon som behövs för replikering och säkerhetskopiering.
Allmän frågelogg— huvudfrågelogg;
Långsam frågelogg— logg över långsamma förfrågningar.

Felloggen

Den här loggen innehåller alla fel som uppstod när servern kördes, inklusive kritiska fel, såväl som serveravstängningar, serverstarter och varningar. Det är här du bör börja i händelse av ett systemfel. Som standard matas alla fel ut till konsolen (stderr), du kan också logga fel till syslog (standard på Debian) eller en separat loggfil:

Log_error=/var/log/mysql/mysql_error.log

# Fel kommer att skrivas till mysql_error.log

Vi rekommenderar att du håller den här loggen aktiverad för att snabbt identifiera fel. Och för att förstå vad det här eller det felet betyder, har MySQL perror-verktyget:

Shell> perror 13 64 OS felkod 13: Tillstånd nekad OS felkod 64: Maskinen är inte på nätverket

# Förklarar innebörden av felkoder

Binär (aka binär) logg

Alla databasmodifieringskommandon registreras i den binära loggen, användbara för replikering och återhämtning.

Det tänds så här:

Log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 5 max_binlog_size = 500 miljoner

# Indikerar plats, livslängd och maximal storlek fil

Observera att om du inte ska skala systemet och implementera feltolerans, är det bättre att inte aktivera den binära loggen. Det är resurskrävande och minskar systemets prestanda.

Begäran logg

Den här loggen innehåller alla mottagna SQL-frågor och information om klientanslutningar. Kan vara användbart för indexanalys och optimering, samt för att identifiera felaktiga frågor:

General_log_file = /var/log/mysql/mysql.log general_log = 1

# Inkluderar loggen och anger filens plats

Du kan också aktivera/inaktivera det medan MySQL-servern körs:

SET GLOBAL general_log = "PÅ"; SET GLOBAL general_log = "AV";

# Du behöver inte starta om servern för att använda den

Långsam förfrågningslogg

Loggen är användbar för att identifiera långsamma, det vill säga ineffektiva frågor. Läs mer i Denna artikel.

Visa loggar

För att se loggar på Debian (Ubuntu) måste du köra:

# Error log tail -f /var/log/syslog #Query log tail -f /var/log/mysql/mysql.log # Logga långsamma förfrågningar tail -f /var/log/mysql/mysql-slow.log

# Om loggarna inte specificeras separat, finns de i /var/lib/mysql

Loggrotation

Glöm inte att komprimera (arkivera, rotera) loggfiler så att de tar mindre plats på servern. För att göra detta, använd verktyget logrotera genom att redigera konfigurationsfilen /etc/logrotate.d/mysql-server:

# - Jag lade allt i ett block och la till sharedscripts, så att mysql får # flush-logs"d bara en gång. # Annars skulle de binära loggarna automatiskt öka med n gånger varje dag. # - Felloggen är föråldrad, meddelanden går till syslog nu./var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log( daglig rotera 7 missingok skapa 640 mysql adm komprimera sharedscripts postrotate test -x /usr/bin/mysqladmin || exit 0 # Om detta misslyckas, kontrollera debian.conf! MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf" if [ -z "`$MYADMIN ping 2>/dev/null`" ]; sedan # Verkligen ingen mysqld eller snarare en saknad debian-sys-maint-användare? # Om detta inträffar och inte är ett fel, rapportera en bugg. #if ps cax | grep -q mysqld; sedan if killall -q -s0 -umysql mysqld; avsluta sedan 1 fi else $MYADMIN flush-logs fi endscript )

# Komprimerar och arkiverar nödvändiga loggar, rensar filer

DDL-logg

MySQL upprätthåller också en dataspråklogg. Den samlar in data från operationer som DROP_TABLE och ALTER_TABLE. Loggen används för att återställa från fel som inträffade under sådana operationer. DDL Log är en binär fil och är inte avsedd att läsas av användaren, så ändra eller ta inte bort den.

Det viktigaste

Slå alltid på felloggen, använd frågeloggen för att kontrollera applikationens anslutning till databasen, kontrollera frågor och funktion. Loggen över långsamma frågor är användbar för att optimera MySQL-prestanda.

Profileringsfrågor i Mysql används för att utvärdera prestandan för din applikation. När du utvecklar medelstora till stora applikationer måste du hantera hundratals förfrågningar fördelade över din kod som exekveras varje sekund. Utan frågeprofileringstekniker kan det vara mycket svårt att ta reda på vad som gör att din applikations prestanda blir lidande.

Vad är den långsamma frågeloggen i MySQL?

MySQL Slow Query Log - en logg som flaggar långsamma och potentiellt problematiska frågor. MySQL stöder denna funktion som standard, men den är inaktiverad. Genom att ställa in vissa servervariabler kan vi specificera vilka förfrågningar vi är intresserade av. Oftast behöver vi frågor som kräver en viss tid att slutföra eller frågor som inte behandlar index korrekt.

Ställa in profileringsvariabler

Huvudvariabler för att ställa in frågeloggen:

Slow_query_log G slow_query_log_file G long_query_time G / S log_queries_not_using_indexes G min_examined_row_limit G / S

Kommentar: G - globala variabler, S - systemvariabler

slow_query_log - booleskt värde inklusive logg
slow_query_log_file - absolut sökväg till loggfilen. Ägaren till katalogen måste vara en användare mysqld, och katalogen måste ha rätt läs- och skrivbehörighet. Oftast körs mysql-demonen som en användare mysql.

För att kontrollera, kör följande kommandon:

Ps-ef | grep bin/mysqld | skär -d" " -f1

Utdata från kommandot kommer att ge dig namnet på den aktuella användaren och mysqld-användaren. Exempel på inställning av /var/log/mysql-katalogen:

Cd /var/log sudo mkdir mysql sudo chmod 755 mysql sudo chown mysql:mysql mysql

long_query_time - tid i sekunder för att kontrollera frågans varaktighet. Till exempel, med ett värde på 5, loggas varje begäran som varar i mer än 5 sekunder.
log_queries_not_using_indexes - booleskt värde, gör det möjligt att spara frågor som inte använder index. Sådana frågor är mycket viktiga i analysen.
min_examined_row_limit - anger minimivärdet för antalet datarader som ska analyseras. Ett värde på 1000 ignorerar frågor som returnerar mindre än 1000 rader med värden.

Dessa variabler kan ställas in i MySQL-konfigurationsfilen, dynamiskt via MySQL-gränssnittet eller MySQL-kommandoraden. Om variablerna är specificerade i konfigurationsfilen kommer servern att installera dem nästa gång den startar. Vanligtvis finns den här filen på /etc, /usr, /etc/my.cnf eller /etc/mysql/my.cnf. Här är kommandona för att söka efter konfigurationsfilen (ibland bör du utöka sökningen till andra rotkataloger):

Hitta /etc -name my.cnf hitta /usr -name my.cnf

När du hittar filen lägger du till de nödvändiga variablerna i avsnittet:

; ... slow-query-log = 1 slow-query-log-file = /var/log/mysql/localhost-slow.log long_query_time = 1 log-queries-not-using-indexes ; ingen mening behövs här

Ändringarna kommer bara att träda i kraft nästa gång du startar MySQL; om du behöver ändra parametrar dynamiskt, använd andra metoder för att ställa in variabler:

Mysql> SET GLOBAL slow_query_log = "PÅ"; mysql> SET GLOBAL slow_query_log_file = "/var/log/mysql/localhost-slow.log"; mysql> SET GLOBAL log_queries_not_using_indexes = "PÅ"; mysql> SET SESSION long_query_time = 1; mysql> SET SESSION min_examined_row_limit = 100;

Du kan kontrollera värdena för variabler enligt följande:

Mysql> VISA GLOBALA VARIABLER SOM "slow_query_log"; mysql> VISA SESSIONSVARIABLER SOM "long_query_time";

Den största nackdelen med en dynamisk installation är att värdena kommer att gå förlorade när systemet startar. Det rekommenderas att ange viktiga parametrar i MySQL-konfigurationen.

Anteckningen: Syntax för dynamisk inställning av parametrar via SET kommando och att använda konfigurationsfilen är något annorlunda, till exempel slow_query_log / slow-query-log . Du hittar en fullständig beskrivning av syntaxen i den officiella DBMS-dokumentationen. Option-File-formatet används för konfigurationsfilen, System Variable Name - variabelnamn när du ställer in värden dynamiskt.

Generera data för frågeprofilering

Vi har gått igenom huvudpunkterna för att sätta upp profilering, nu kommer vi att skapa de frågor som intresserar oss. Det här exemplet användes på en körande MySQL-server utan några preliminära logginställningar. Exempelfrågor kan startas både genom MySQL GUI och DBMS kommandoverktyg. Vid övervakning av loggen över långsamma frågor är det vanligt att öppna två fönster med en anslutning: ett för att köra frågor, det andra för att se loggen.

$> mysql -u -p mysql> SKAPA DATABAS profile_sampling; mysql> ANVÄND profile_sampling; mysql> CREATE TABLE-användare (id TINYINT PRIMARY KEY AUTO_INCREMENT, namn VARCHAR(255)); mysql> INSERT INTO users (namn) VÄRDEN ("Walter"),("Skyler"),("Jesse"),("Hank"),("Walter Jr."),("Marie"),("Saul") "),("Gustavo"),("Hector"),("Mike"); mysql> SET GLOBAL slow_query_log = 1; mysql> SET GLOBAL slow_query_log_file = "/var/log/mysql/localhost-slow.log"; mysql> SET GLOBAL log_queries_not_using_indexes = 1; mysql> SET long_query_time = 10; mysql> SET min_examined_row_limit = 0;

Nu har vi en databas med testdata. Vi lanserade profilering, men vi har medvetet ställt in svarstiden och antalet rader på små. För att se loggen använd kommandot:

Cd /var/log/mysql ls -l

I teorin borde loggfilen inte existera ännu, eftersom vi inte har gjort frågor till databasen. Om det finns betyder det att profilering konfigurerades tidigare, och detta kan förvränga resultaten av exemplet. Kör i konsolen:

Mysql> ANVÄND profile_sampling; mysql> SELECT * FROM användare WHERE id = 1;

Vår fråga använder primärnyckelindexet från tabellen. Förfrågan behandlades mycket snabbt med hjälp av indexet, så det bör inte återspeglas i loggen. Observera att loggfilen inte borde ha skapats.

Gör nu följande:

Mysql> SELECT * FROM användare WHERE name = "Jesse";

Här använde vi inte index. Vi bör nu se denna begäran i loggen:

Sudo cat /var/log/mysql/localhost-slow.log # Tid: 140322 13:54:58 # User@Host: root @ localhost # Query_time: 0,000303 Lock_time: 0,000090 Rows_sent: 1 Rows_examined_sampled: 10; SET timestamp=1395521698; SELECT * FROM användare WHERE name = "Jesse";

Låt oss titta på ett annat exempel. Höj ribban för antalet rader i svaret och kör följande fråga:

Mysql> SET min_examined_row_limit = 100; mysql> SELECT * FROM användare WHERE name = "Walter";

Förfrågan kommer inte att återspeglas i loggen, eftersom vi inte översteg 100 rader i svaret på förfrågan.

Anteckningen: Om data inte visas i loggen, måste du först och främst ta hänsyn till följande faktorer. Den första är rättigheterna till katalogen där loggfilen är lagrad. Gruppen och användaren måste motsvara mysqld-användaren, rättigheterna måste vara chmod 755. För det andra kan profilering ha konfigurerats tidigare. Ta bort alla befintliga profileringsvariabelvärden från konfigurationsfilen och starta om servern eller ställ in variablerna dynamiskt. Om du använde den dynamiska metoden kommer du att avsluta och logga in på MySQL-konsolen igen.

Analys av frågeprofileringsdata

Tänk på exemplet ovan:

# Tid: 140322 13:54:58 # Användare@värd: root @ lokalvärd # Fråga_tid: 0,000303 Lås_tid: 0,000090 Rader_sänt: 1 Rader_undersökt: 10 använd profilsampling; SET timestamp=1395521698; SELECT * FROM användare WHERE name = "Jesse";

Här ser vi:

Tidpunkt då förfrågan startade
Användaren som gjorde begäran
Öppettider önskemål
Låsets varaktighet
Antal markerade rader
Antal rader som analyserats

Denna information är mycket användbar, eftersom vi med dess hjälp kan hitta och eliminera orsaken till systemets avmattning. Dessutom kommer en MySQL-utvecklare eller administratör alltid att kunna se problematiska frågor och jag skulle vilja notera att det är mycket snabbare att hitta dem här än att studera applikationskoden. Med långtidsprofilering kan du övervaka driftförhållandena vid låg hastighet.

Använder mysqldumpslow

Loggen registrerar ständigt data, som regel skriver den mycket mer än vad som läses från den. På stor storlek log, blir det problematiskt att läsa den. MySQL innehåller ett verktyg som heter mysqldumpslow som hjälper till att upprätthålla loggintegritet. Själva programmet kombineras med MySQL (på Linux-system). För att använda den, följ det nödvändiga kommandot och skicka sökvägen till loggfilen:

Sudo mysqldumpslow -t 5 -s på /var/log/mysql/localhost-slow.log

Det finns ett antal parametrar som hjälper dig att anpassa kommandoutgången. I exemplet nedan ser vi de senaste fem förfrågningarna sorterade efter genomsnittlig varaktighet. Som ett resultat blir det mycket bekvämare att läsa loggen. (utgången modifierad för att visa faktiska loggvärden):

Antal: 2 Tid=68,34s (136s) Lås=0,00s (0s) Rader=39892974,5 (79785949), root@localhost VÄLJ PL.pl_title, P.page_title FRÅN sida P INNER JOIN sidlänkar PL ON PL.pl_namespace = P.pl_namespace WHERE P.page_namespace = N ...

Vad vi ser:

Antal - antal förekomster av begäran i loggen
Tid - genomsnittlig och total förfrågningstid
Lås - bordslåstid
Rader - Antal markerade rader

Kommandot utesluter numerisk och strängfrågedata, vilket betyder att frågor med samma WHERE-sats kommer att betraktas som desamma. Tack vare detta verktyg behöver du inte ständigt titta på loggen. På grund av det stora antalet kommandoparametrar kan du sortera utdata som du vill. Det finns också utvecklingar från tredje part med liknande funktionalitet, till exempel pt-query-digest.

Begär uppdelning

Du bör vara uppmärksam på ett annat verktyg som låter dig bryta ner komplexa frågor. Oftast måste man ta en fråga från loggen och sedan köra den direkt i MySQL-konsolen. Först måste du aktivera profilering och sedan köra frågan:

Mysql> SET SESSION profilering = 1; mysql> ANVÄND profile_sampling; mysql> SELECT * FROM användare WHERE name = "Jesse"; mysql> VISA PROFILER;

Efter att ha aktiverat profilering visar SHOW PROFILES en tabell som länkar Query_ID och SQL-uttryck. Hitta motsvarande Query_ID och kör följande fråga (ersätt # med ditt Query_ID):

Mysql> SELECT * FROM INFORMATION_SCHEMA.PROFILING WHERE QUERY_ID=#;

Exempel på utdata:

SEKV STAT VARAKTIGHET 1 börjar 0,000046 2 kontrollbehörigheter 0,000005 3 öppningstabeller 0,000036

STAT- ett steg i processen att verkställa en begäran, VARAKTIGHET- stegets varaktighet i sekunder. Det här verktyget används inte särskilt ofta, men ibland kan det vara extremt användbart för att fastställa orsaken till långsam frågeprestanda.

Detaljerad beskrivning av kolumnerna:

Detaljerad beskrivning av steg:

Anteckningen: Det här verktyget ska inte användas i serverproduktionsläge, förutom för att analysera specifika frågor.

Långsam frågeloggprestanda

Den sista frågan är hur profilering påverkar serverns prestanda som helhet. I serverns produktionsläge kan du ganska säkert använda sådan loggning, det bör inte påverka vare sig CPU eller I/O. Det är dock värt att vara uppmärksam på storleken på loggfilen, den bör inte bli oöverkomligt stor. Jag skulle också vilja notera av erfarenhet att inställning av värdet för variabeln long_query_time till 1 sekund eller högre.

Viktig: Du bör inte använda profileringsverktyget - SET profiling = 1 - för att registrera alla förfrågningar, d.v.s. Det rekommenderas inte att använda variabeln general_log i produktläge och under tung belastning.

Slutsats

Frågeprofilering kan hjälpa dig mycket med att isolera den problematiska frågan och bedöma den övergripande prestandan. Utvecklaren kan också studera hur MySQL-frågorna i hans applikation fungerar. Verktyget mysqldumpslow hjälper dig att visa och bearbeta frågeloggar. Efter att ha identifierat problematiska frågor återstår bara att ställa in dem för maximal prestanda.

Begrepp

Serverloggar (loggfiler, serverlogg)- filer lagrade på servern som innehåller systeminformation om servern, samt loggar all möjlig data om besökaren av webbresursen.

Loggar används av systemadministratörer för att analysera besökare, studera beteendemönstren för vissa grupper av användare, samt få olika information om dem, såsom: webbläsaren som används, IP-adress, data om kundens geografiska plats och mycket mer. Förutom analys kan du på detta sätt ta reda på om obehörig åtkomst till webbplatsen, ta reda på mer exakt vem som exakt skapade den och överföra data om detta fall till lämpliga myndigheter.

Datan i loggfilen, i sin rena form, kommer inte att vara förståelig för vanliga användare, som i allt detta bara kommer att se en uppsättning tecken i en obegriplig ordning. Men för systemadministratörer och webbutvecklare, detta är en mycket läsbar text och ganska användbar information.

Rad av händelser

Varje gång en klient kommer åt en webbresurs utlöses flera händelser samtidigt, vars sekvens vi kommer att prata om.

1. Göra en sidförfrågan. När du anger en adress i webbläsarraden, eller när du följer en aktiv webblänk, till exempel från en sökmotors resultatsida, söker webbläsaren och ansluter till servern där sidan finns och gör en begäran om det. Samtidigt överför den följande information till servern:
- IP-adressen för klientdatorn som begär sidan (om du använder en proxyserver, IP-adressen till din proxy);
- adress till internetsidan som begärs av användaren (IP-adress);
- Exakt tid och datum då begäran gjordes.
- data om den faktiska platsen för klienten (om en proxyserver används, då den faktiska proxyadressen);
- information om webbläsaren som används av klienten (namn, version, etc.);
- data om webbsidan som klienten överförde från.

2. Överföring av de begärda uppgifterna. Den begärda informationen (webbsida, filer, cookies etc.) överförs från servern till användarens dator.

3. Skriv till serverloggen. Efter allt uppstår en loggpost, som indikerar all data som dykt upp under de senaste två händelserna. Detta är all information som skickas i första stycket, samt information om de överförda uppgifterna.

Hur man visar serverloggar

Loggfiler lagras i en fil access.log oavsett vilken typ av webbserver du använder (Apache, Nginx, squid proxyserver, etc.) Den här filen är textdokument, på varje rad varav ett överklagande är skrivet. Inspelningsformat i access.log ganska mycket, men den mest populära kombineras, där posten har följande form och sekvens:

Kod: %h %l %u %t \"%r\" %>s %b \"%(Referer)i\" \"%(User-Agent)i\"
Var:

%h- värd/IP-adress från vilken begäran gjordes;
%t- tid för begäran till servern och serverns tidszon;
%r- version, innehåll och typ av begäran;
%s- HTTP-statuskod;
%b- antalet byte som skickas av servern;
%(Referent)- URL-källa för begäran;
%(User-Agent)- HTTP-huvud, med information om begäran (klientapplikation, språk, etc.);
%(Värd)- namnet på den virtuella värd som nås.

När den är klar ser den här raden ut ungefär så här:

127.0.0.1 - - "GET /index.php HTTP/1..0 (kompatibel; MSIE 7.0; Windows NT 5.1)"

Att läsa loggar manuellt kommer att ta ganska mycket tid och ansträngning. Därför använder erfarna webmasters speciell programvara som kallas "Log File Analyzers". De analyserar all data, vilket är ganska svårt för människor att läsa, och producerar strukturerad data. Dessa är program som: Analog, WebAnalizer, Webalizer, Awstats, Webtrends, etc. Typer av speciella programvara ganska mycket, bland dem finns det liknande betalda program, och gratis. Därför är jag säker på att alla kommer att hitta något som de gillar.

Var man hittar webbplatsloggar

Om du har regelbunden värd, måste du troligen skriva till din värd och begära loggar från honom. Dessutom, ganska ofta, kan du begära dem via värdpanelen. Olika värdar gör det olika. Till exempel, för att begära från min värd, klicka bara på startsida paneler:

Om du har tillgång till systemmappar server, då kan du hitta loggarna på /etc/httpd/logs/access_log i 99 fall av 100.

Fellogg error.log

Felloggen- en fil där loggar också förs. Men inte besökare, utan fel som uppstod på servern. Som fallet är med access.log, varje rad i filen är ansvarig för ett fel som uppstod. Inspelningen utförs med hänsyn till sådan information som: exakt datum och tid för felet, IP-adressen till vilken felet utfärdades, typen av fel samt orsaken till dess uppkomst.

Slutsats

Loggar är ett ganska kraftfullt och informativt verktyg att arbeta med. Men nuförtiden ersätts de av verktyg som Yandex.Metrica, Google Analytics, etc., vilket gör våra liv enklare. Men om du planerar att utvecklas, växa och lära dig något nytt rekommenderar jag verkligen att du lär dig detta ämne bättre.

Populär i kategorin: